bcmsh is blocking bcmcmd, and no timeout either

[zhenggen-xu]

Description

/var/run/sswsyncd/sswsyncd.socket seems to only allow one client, this is problematic especially when we have bcmsh enabled. If some one is using bcmsh, and bcmcmd will hang there. Ever worse, bcmsh does not time-out, so bcmcmd could be blocked there forever until you kill the bcmsh.

Steps to reproduce the issue:

1. run bcmsh
   a# bcmsh
   Press Enter to show prompt.
   Press Ctrl+C to exit.
   drivshell>

2. bcmcmd ps
   <== stuck here

Describe the results you received:

Describe the results you expected:

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

```
(paste your output here)
```

**Attach debug file `sudo generate_dump`:**

```
(paste your output here)
```

[lguohan]

what's your expectation?

[lguohan]

we can only support one client at one time. The drivshell is not designed to support multiple shells.

[zhenggen-xu]

If only one shell is supported, if we start bcmsh, we should print the "warning" messages so people will be careful of using it as it could block regular CLI.

Second, if someone runs bcmsh today and close the terminal, no timeout was done, bcmcmd etc will be blocked forever. We should enable time out to close bcmsh automatically, or at least bcmcmd related CLI should detect bcmsh and print messages to let user act.

[lguohan]

address in #1921 . add inactivity timer.

bcmcmd has default timemout, it will not block forever.

[zhenggen-xu]

Based on my testing, there was no default timeout, I connect socat to the UNIX socket and kill the terminal, it never (at least hours) exits and no bcmcmd command can run after that unless you kill that socat session.

[svc-acs]

can you elaborate, did you test #1921.

[zhenggen-xu]

The comments were for bcmsh testing before the changes in #1921. After the changes, it should be fine. You can close this.