Incorrect handling of signal handlers

[mcopik]

Hi!

I'm experiencing the same problem as issues #187 and #188. As soon as I start the server, Crow steals signals handlers even if I call signal_clear before. It was very confusing, but I was able to dig into the library's code and find out the source. In fact, I think it's caused by two separate issues:

(1) I use SSL App and the SSL implementation doesn't clear the signals in the server implementation at all. - app.h, line 279 I manually added the code from the non-SSL version. This helped partially - Crow didn't register signals, but it still overrode them and I had no signals at all after running run.

(2) Finally, I was able to find out that just creating the signal_set from Boost Asio affects OS signal handling. And since they are created inside the constructor of http_server, which instance is dynamically allocated in run, it will clear SIGINT but not start a handler. I fixed the issue for myself by changing the constructor to allocating an empty set - maybe it could be a generic solution if signal handlers are always added anyway by entities using this class?

[The-EDev]

Interesting find, Thanks a lot.

1. Seems like an oversight while working on [fix] Make signal handler optional #85, Thanks for pointing it out.
2. Not exactly an oversight, but the code wasn't changed when [fix] Make signal handler optional #85 was added.

Thanks again for the detailed description, both issues will be fixed promptly.

[samichoulo911]

I am having a similar issue where signals were still being intercepted after server.stop() was called. Is there a reason why the stop() method doesn't call signal_clear() ?

[The-EDev]

@samichoulo911 if you're calling server.stop() on your own you should probably clear the signals before you start the application, at least when it comes to normal operations.

The reason stop() doesn't clear the signals is that the Crow app was not designed to be manipulated after calling run(). Therefore the effects of doing so (if any) are unknown at this time.
You do bring up a good point in clearing the signals and I do want to look into it. But considering it's more of a feature rather than a bug, I do believe it is outside this issue's scope.

[samichoulo911]

Thank for the explanation! When poking around the code trying to see who was using the signals I noted that the run() method calls signal_clear() right before adding them back to signals (see image). This is most probably out of this issue's scope, but I was just curious to know the reasoning behind.

[The-EDev]

I believe this is because (prior to #296) the server's constructor would use default signals SIGINT and SIGTERM, so the app would need to clear those before adding custom signals.

[samichoulo911]

This clears up my confusion thanks!