Need more QS host locks

prjemian commented 2 months ago

Need to apply additional locks to prevent starting rogue QS host processes (via start-re-manager).

[x] Different workstation, same account and ~/bluesky directory
[ ] Same workstation, different account and same bluesky directory as above
[ ] Same workstation, different account and different bluesky directory than above
[ ] Different workstation, different account and different bluesky directory than above

Thanks, Andrew Chuang, for the request!

prjemian commented 2 months ago

The command: qserver status --zmq-control-addr tcp://${WORKSTATION}:60615 can be used to query the QS daemon (that uses the default control port) on a specific WORKSTATION. If the server is running, it will respond promptly. If no server is running, the command will timeout, like this:

Arguments: ['status']
ERROR:bluesky_queueserver.manager.comms:ZeroMQ communication failed: timeout occurred
Traceback (most recent call last):
  File "/home/beams/S1IDTEST/.conda/envs/bluesky_2024_1/lib/python3.11/site-packages/bluesky_queueserver/manager/comms.py", line 1047, in _zmq_receive
    raise Exception("timeout occurred")
Exception: timeout occurred
15:14:22 - ERROR: ZMQ communication error: timeout occurred

timeout in ~2.5s

prjemian commented 2 months ago

Successful status request in ~0.7s

BCDA-APS / bluesky_training

Need more QS host locks #293