gconfd does not unblock signals properly

Bug #188007 reported by Isaac Clerencia on 2008-02-01
2
Affects Status Importance Assigned to Milestone
gconf
Fix Released
Medium
gconf (Ubuntu)
Medium
Ubuntu Desktop Bugs

Bug Description

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

Related branches

Isaac Clerencia (isaaccp) wrote :

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

Pedro Villavicencio (pedro) wrote :

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

Changed in gconf:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Triaged
Changed in gconf:
status: Unknown → New
Daniel Holbach (dholbach) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in gconf:
status: Triaged → Fix Committed
Changed in gconf:
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in gconf:
status: Fix Committed → Fix Released
Changed in gconf:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.