Runing slr a second time makes original cluster unmanageable

[grimborg]

I've noticed that if I run slr a second time (by mistake), the original cluster becomes unmanageable.

$ slr --pid pid_file --size 4 --detach my/server.js
$ slr
--whoops, I meant slrc, ctrl-C
$ slrc
Communication error (connect ENOENT), check master is listening 

The original cluster is still running, but slrc can no longer communicate with the master.

Is this the intended behaviour? Is there a way for slr to check whether it's already running?

Thanks

[rmg]

The problem is that the way the process detaches makes it harder to check for these sorts of error conditions and report them in a useful way.

This is one of the problems with detach that led us to create strong-pm.

What is the purpose of using --detach in this case?

[sam-github]

The core problem is that slrc needs a fixed address to connect to. It happens to use unix domain sockets, the runctl socket (configurable, of course, but thats the default). When you run again, the new slr grabs the socket, so now the first slr doesn't have it. I could fail out.... but unfortunately, unix domain sockets have the unfortunate characteristic that they live past process death, and you can't tell if they are alive or not. At least not easily, though I think I just thought of a way.

All of which is to say, I'm not sure what we could do differently. But I would suggest never running detached! Use multiple terminals, tmux if you can, and run the supervisor in one, the runner in the other.