GNOME Bugzilla – Bug 350501
handle sigterm, sigquit, etc. gracefully
Last modified: 2007-01-23 00:44:16 UTC
Hello, A Debian user suggested the following at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272959: --- 8< --- This might be a bit over the top but it's something that's bugged me about pan. It won't write metadata about which messages were read until the program is closed. Therefore, if I turn off the machine by pressing the power button (and letting ACPI handle the shutdown gracefully), pan will be forcibly closed and it will have forgotten all of those read messages. I do this often, and it would be nice to have this feature. --- 8< --- From what I can tell after experimenting with the betas, this still applies. While I usually shut down pan cleanly, I agree with the submitter that this sort of feature would be quite useful. I have only made a few greps of the source to check this, but it seems to me that a simple signal handler for a few of the more important signals (SIGQUIT, SIGTERM leaps to mind) ensuring that data is written to disk would go a long way? If that is already handled, please disregard my suggestion.
primer on handling SIGINT/SIGQUIT: http://www.cons.org/cracauer/sigint.html Looks like the handler could just call g_main_loop_exit in pan.cc and existing code would handle everything else...
Created attachment 70521 [details] [review] first draft Søren, how does this patch look to you? Is it really this simple? :)
*** Bug 120763 has been marked as a duplicate of this bug. ***
The patch looks good to me, although I am not exactly sure how the gtk event loop likes being interrupted and then resumed. According to the signal man page, some weirdness may occur if certain system calls are being executed at the time of the signal. I will give the patch a spin later tonight, or sometime tomorrow if the wifes guests decide to stick around too long.
Having now finally gotten around to testing the patch, it works as expected. However, you should probably trap SIGTERM as well as SIGQUIT and SIGINT, since that is what gets sent by default if the process is killed by means of "kill". Thanks for providing the patch.
Oops, I saw this comment after rolling the 0.108 binary. I'll leave this ticket open and get SIGTERM next release.
Doing a little more digging, IMO 0.108 is doing the wrong thing for sigquit and sigterm too. SIGHUP Modem carrier has dropped SIGINT User changed his mind (Control-C) SIGQUIT User wants core image (Control-\) SIGTERM General software termination signal So SIGINT and SIGTERM should probably be handled the same way, with an orderly shutdown. SIGQUIT should dump core immediately, which is the default handling, so we shouldn't be handling it at all. #120763 suggests that SIGHUP be handled like SIGTERM.
If I can just chip in my 2 cents here.... the way I'd read it, SIGHUP can result in a "Are You Sure?" dialog, so could SIGINT although a CONTROL-C tends to indicate the user is really wanting a termination; whereas SIGTERM is a more generic "this host is going down, tidy up as best you can" and should not result in any kind of user dialog. Hope that helps... Regards, Bevis.
looking around a little more, I found this on xchat-discuss, which says SIGHUP should be handled with a non-interactive, orderly shutdown: http://mail.nl.linux.org/xchat-discuss/2002-04/msg00130.html > > Hello, > > I've added a signal handler for SIGHUP to X-Chat. It causes the logfiles > > to be closed and then reopen (usefull for log rotation). > > Now, how do I get it in the official X-Chat source? > > I've attached the patch (its pretty small) and if anyone wishes for a shell > > script to rotate the logs, just mail me. > > Hmm, this is a bad idea. SIGHUP normal means, the user is logged of. Only for processes which are children of a login shell. The normal meaning for daemons is "reread your config files and reopen your logfiles". > To close the logfiles is a good idea (i dont know, if xchat does it > already). > But catching the SIGHUP and preventing xchat from exit will most times > cause the effect, that the Xserver is gone away and xchat will > crash. What exactly do you think happens when it fails to handle SIGHUP? Crashing due to an unhandled signal isn't much different from crashing due to the X server connection being terminated. Actually gtk will probably handle the latter cleanly and tidy up (not that xchat needs much tidying).
I'm thinking of using this in 0.109: #ifndef G_OS_WIN32 void sighandler (int signum) { std::cerr << "shutting down pan." << std::endl; signal (signum, SIG_DFL); gtk_main_quit (); } #endif // G_OS_WIN32 void register_shutdown_signals () { #ifndef G_OS_WIN32 signal (SIGHUP, sighandler); signal (SIGINT, sighandler); signal (SIGTERM, sighandler); #endif // G_OS_WIN32 }
This draft fix is included in 0.109.
*** Bug 352668 has been marked as a duplicate of this bug. ***