BUG: Even if there are no PID and lock files, there is another rserver process (PID 11065) already running on this machine

[HenrikBengtsson]

Issue

A user reported that rsc start failed because there was already an rserver processing running;

[alice@dev3 ~]$ rsc start
ERROR: Even if there are no PID and lock files, there is another rserver process (PID 11065) already running on this machine (dev3.wynton.ucsf.edu): rserver --config-file=/home/alice/.config/rsc/rserver.conf
Traceback:
1: assert_no_rserver() on line #858 in /wynton/home/cbi/shared/software/CBI/rstudio-server-controller-0.8.3/bin/rsc
2: main() on line #1389 in /wynton/home/cbi/shared/software/CBI/rstudio-server-controller-0.8.3/bin/rsc
Exiting (exit 1)

Troubleshooting

However, it turns out that the conflicting process is owned by another user:

ps -o euser,euid,args -p 9671
EUSER EUID  COMMAND
bob   30303 rserver --config-file=/home/bob/.config/rsc/rserver.conf

Looking at:

https://github.com/UCSF-CBI/rstudio-server-controller/blob/e4e36a537415a36d668d9d94a6fee67db9417a2d/bin/rsc#L848-L865

it's clear that the internal assert_no_rserver() function does not distinguish between the user's rserver processes and ditto run by other users.

Action

• [ ] Make assert_no_rserver() only look at user's processes and ignore others'.

[HenrikBengtsson]

Oh, actually not a bug, because

https://github.com/UCSF-CBI/rstudio-server-controller/blob/e4e36a537415a36d668d9d94a6fee67db9417a2d/bin/rsc#L854

makes it unique to the user.

Either way, it's better to do:

mapfile -t pids < <(pgrep -u "$UID" rserver)

upfront.