Feature #323
Customizable signal handlers in Skylark
| Status: | Approved | Start date: | 09/03/2012 | |
|---|---|---|---|---|
| Priority: | Immediate | Due date: | ||
| Assignee: | Jan Dolinár | % Done: | 100% | |
| Category: | Wpp (web framework) | Spent time: | - | |
| Target version: | - |
Description
What about adding a callback to SkylarkApp that could be called on SIGUSR1 signal?
My current use-case would be assigning ReopenLog() to the callback to allow simple log rotation using logrotate daemon (I would use LOG_ROTATE log option, but it rotates only when restarting application). Also, similar Callback could be added for SIGUSR2, but for now I am happy with one :)
Patch is attached, please review and apply if you think it it won't make any trouble.
sigusr.patch 
(1.49 KB)
History
#1 Updated by Miroslav Fidler over 12 years ago
- Assignee changed from Miroslav Fidler to Jan Dolinár
Should not it be rather virtual method than Callback in this case?
#2 Updated by Jan Dolinár over 12 years ago
- Assignee changed from Jan Dolinár to Miroslav Fidler
You mean making void SkylarkApp::Signal(int signal) virtual? Well, that might be actually even better :) And some of the variables could be protected in this case (quit, main_pid and child_pid), to allow fine control over the signals.
#3 Updated by Miroslav Fidler over 12 years ago
- Status changed from Patch ready to New
- Assignee changed from Miroslav Fidler to Jan Dolinár
Jan Dolinár wrote:
You mean making void SkylarkApp::Signal(int signal) virtual? Well, that might be actually even better :) And some of the variables could be protected in this case (quit, main_pid and child_pid), to allow fine control over the signals.
No, just using virtual method instead of Callback. I mean, it is unlikely that we would want to invoke something outside Skylark derived "MyApp"....
#4 Updated by Jan Dolinár over 12 years ago
Ok, I'll leave to your better judgment. As far as I can use signal for log rotation and similar tasks, I'll be happy :)
#5 Updated by Miroslav Fidler over 12 years ago
- Status changed from New to Ready for QA
#6 Updated by Miroslav Fidler over 12 years ago
- Priority changed from Normal to Immediate
#7 Updated by Miroslav Fidler over 12 years ago
- Status changed from Ready for QA to Approved
#8 Updated by Jan Dolinár over 12 years ago
Hi Mirek,
just one more question: Is there any reason for the fact that the signal handling is only available in the preforked mode? Most signals (SIGTERM,SIGALRM,SIGHUP and SIGINT) are probably not necessary in single process mode, but I believe that at least the SIGUSR1 handler should be set always.