excessive cleanup on shutdown

[GoogleCodeExporter]

imsettings is currently triggering a bug in glib when it is shutting down, 
meaning that the whole desktop shutdown is delayed about 20 seconds with 
systemd. Filed at https://bugzilla.gnome.org/show_bug.cgi?id=660637

However, while investigating that, it was noted that imsettings is being 
excessively "clean" on shutdown. As nothing special needs to be done on 
shutdown other than closing connections and freeing memory, it would be 
sensible (and a signification) just to let the TERM signal terminate the 
process instantly. This was suggested here:
http://lists.freedesktop.org/archives/dbus/2011-September/014718.html

Here is a patch which implements that change (and also avoids the glib bug).

Original issue reported on code.google.com by dsdr...@gmail.com on 1 Oct 2011 at 5:10

Attachments:

• simplify-exit.patch

[GoogleCodeExporter]

forgot to mention. the imsettings-server.c hunk simply makes it so that we 
don't try to release a bus name that we don't own when shutting down due to the 
"disconnected" signal.

Original comment by dsdr...@gmail.com on 1 Oct 2011 at 5:11

[GoogleCodeExporter]

Thank you for reporting. well, the signal handler is needed to ensure the IM 
processes is shut down when the signals received, though.

Original comment by ak...@tagoh.org on 3 Oct 2011 at 1:49

[GoogleCodeExporter]

Not exactly - the kernel does that for you. The default actions of both SIGTERM 
and SIGINT are to terminate the process. See "man 7 signal"

Original comment by dsdr...@gmail.com on 3 Oct 2011 at 7:46

[GoogleCodeExporter]

that's right if the IM is just working as the foreground process. basically 
they are working as the daemon and imsettings is watching the process to save 
the logs and to restart the process when it accidentally killed.

try to install ibus and uim (and uim-gnome) and see what happens when you 
select it on im-chooser say and kill imsettings-daemon with your patch. I think 
the IM processes keeps running after changing the parent process id to 1.

Original comment by ak...@tagoh.org on 3 Oct 2011 at 7:56

[GoogleCodeExporter]

You're right, sorry about that. A signal handler is indeed needed for that case.

BTW, just in case you're interested, here is another patch I was playing with 
before I had narrowed down my earlier issue to a glib bug. It simplifies the 
signal handling and makes it safer (its technically not safe to call glib 
functions from a signal handler). But its really just a cleanup and doesn't fix 
any problems I could reproduce. It also requires glib-2.30. 

Original comment by dsdr...@gmail.com on 3 Oct 2011 at 12:39

Attachments:

• signal-handler.patch

[GoogleCodeExporter]

Thanks for the patch. I'd love to see that simplified. though my main 
development environment is still Fedora 15, which doesn't have glib 2.30. so 
pondering to apply it a bit later.

Anyway, the dbus issue should be fixed in git at least.

Original comment by ak...@tagoh.org on 26 Oct 2011 at 7:47

• Changed state: Accepted