gconfd does not unblock signals properly

[Isaac Clerencia]

Binary package hint: libgconf2-4

This bug has already been submitted to upstream, but they won't react:
http://bugzilla.gnome.org/show_bug.cgi?id=505488

When gconfd-2 is started it does not unblock signals properly. This becomes an
issue when the following two conditions are satisfied:

- The gconf library is used from a process which has previously blocked some
signals
- The process is responsible for launching the daemon for first time.

If that happens gconfd-2 will not receive some signals which are supposed to be
delivered, such as SIGHUP, SIGTERM...

Steps to reproduce:
1. kill any gconfd-2 process
2. use the library from a process which blocks signals like HUP, TERM
3. try to send SIGTERM or SIGHUP signals

[Isaac Clerencia (isaaccp)]

Here is a patch that fixes the problem by unblocking all the signals

[Pedro Villavicencio (pedro)]

thanks for your report and work, Sebastien may you take a look to it? thanks.

[Daniel Holbach (dholbach)]

To get your fix included in Ubuntu, try transforming it into a debdiff (http://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) and submitting it for review (http://wiki.ubuntu.com/SponsorshipProcess).

[Sebastien Bacher (seb128)]

Thank you for your work there, looks like a corner case, we will wait to get upstream comments before using the change

[Isaac Clerencia (isaaccp)]

Hi Sebastien.

I was fearing this answer :P Thing is upstream doesn't seem to be responsive at all, we even joined the #gnome-hackers IRC channel and were told that it's quite unlikely that anyone answers because gconf has no upstream maintainer.

If something important breaks there somebody takes care of it, but it's not like there is somebody taking real care of it. I know this is a corner case, but it bites us. eBox (which we are trying to get into Ubuntu for Hardy) uses gconf as configuration backend.

eBox is a web frontend for server configuration. apache2 blocks some signals and if gconfd is spawned from within apache2 it's not possible to terminate it gracefully.

I realise that gconf is a quite critical component in Ubuntu, but the change is really small and not intrusive. In any case we have a relatively clean hack to deal with this issue in case gconf can't be patched in time for Hardy.

Best regards

[Sebastien Bacher (seb128)]

Vincent Untz reviewed the change and commited to the upstream SVN, will be in hardy with the next update

[Launchpad Janitor (janitor)]

This bug was fixed in the package gconf - 2.22.0-0ubuntu2

---------------
gconf (2.22.0-0ubuntu2) hardy; urgency=low

  * debian/patches/90_from_svn_unblock_signals.patch:
    - change from SVN, unblock the signals when started (lp: #188007)

 -- Sebastien Bacher <email address hidden> Tue, 15 Apr 2008 00:11:50 +0200