using Crossbar.io with supervisor - listener socket not closed on signal from supervisor / exit from script

[Dave Barndt]

Hi,

Quick question - can Crossbar.io (the "crossbar start" command) be used with supervisor utility?

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?

Sorry if this is a dumb question!

Thanks for any light,

Dave

[Dave Barndt]

Hmmm. I'm not exactly sure what happened, but when I pushed my latest app version to be used by supervisor, it now works. I'm having supervisor send a SIGINT ([program] configuration setting "stopsignal=INT" and "stopasgroup=true").

I'll keep an eye on it in case I see it happen again. Meantime, sorry, never mind, etc.  :^)

Dave

[Tobias Oberstein]

Hi Dave,

Am 18.12.2014 19:28, schrieb Dave Barndt:
> Hi,
>
> Quick question - can Crossbar.io (the "crossbar start" command) be used
> with supervisor utility?

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.

>
> 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?

/Tobias

>
> Sorry if this is a dumb question!
>
> Thanks for any light,
> Dave
>

> --
> You received this message because you are subscribed to the Google
> Groups "Autobahn" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autobahnws+...@googlegroups.com
> <mailto:autobahnws+...@googlegroups.com>.
> To post to this group, send email to autob...@googlegroups.com
> <mailto:autob...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autobahnws/ca650472-cf83-40f7-8778-c9a5e47e6623%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/ca650472-cf83-40f7-8778-c9a5e47e6623%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Dave Barndt]

Hi Tobias,

On Friday, December 19, 2014 4:46:39 AM UTC-5, Tobias Oberstein wrote:

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 <port>" 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.

[program:lj_wwwService]

command=/var/www/lj_wwwService

user=www-data

autostart=true

startsecs=10

autorestart=unexpected

stopasgroup=true

Dave