We often run Crossbar.io from mechanisms like systemd or Daemontools.
These take care of starting Crossbar.io at system boot time and restart
it should it exit.
Yes, supervisor seems to work now too. I think what fixed my problem was to specify the supervisor “stopasgroup” config value as “true” for the script I run that launches Crossbar.io. More below…
When I run Crossbar.IO interactively, I just hit CTRL-C - the
“SIGINT”-like-keyboard-interrupt signal is caught, Crossbar.io exits
cleanly, and its listener sockets are closed properly.
But when I try running Crossbar.IO within supervisor, when supervisor
terminates it sends a SIGTERM (by default; I also tried changing it to
send SIGINT) to processes it’s controlling. Crossbar.io does exit, but
the socket is not cleaned up. I assume this is because the shutdown was
not clean somehow, maybe because supervisor sent a SIGKILL later. Does
Crossbar.io (“crossbar start”) handle various signals that an external
entity could send it?
The Crossbar.io node controller process that is started for a node (and
always runs) should handle all relevant signals. E.g. when the node
controller process is killed, all forked child processes (workers) also
exit. Twisted does all signal handling and is usally quite good at it,
but who knows. How did you detect a socket would not have been cleaned up?
Initially, I noticed the problem when I tried stopping/restarting Crossbar.io via supervisor. Crossbar.io complained that the desired listener socket was in use. A "netstat -a | grep " revealed that the port was still open and in a “LISTEN” state. I rebooted to clear the condition and tried various changes to the supervisor config, but I think the “stopasgroup” setting was the key one. In case it might help someone else, here are the others I’m currently using that would apply. Again, supervisor is invoking a script that calls “crossbar start”, as opposed to invoking “crossbar start” directly.
On Friday, December 19, 2014 4:46:39 AM UTC-5, Tobias Oberstein wrote: