After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 505488 - gconfd does not unblock signals properly
gconfd does not unblock signals properly
Status: RESOLVED FIXED
Product: GConf
Classification: Deprecated
Component: gconf
2.20.x
Other All
: Normal normal
: ---
Assigned To: GConf Maintainers
GConf Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-12-24 21:45 UTC by Javier Uruen Val
Modified: 2008-03-19 13:42 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch against gconf 2.20.1 to unblock signals (625 bytes, patch)
2007-12-24 21:49 UTC, Javier Uruen Val 		committed Details | Review

Description Javier Uruen Val 2007-12-24 21:45:53 UTC 
Please describe the problem:
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. 


Actual results:
Signals cannot be delivered 

Expected results:
Signals should be delivered

Does this happen every time?
Yes

Other information:
I have a small patch which takes care of unblocking signals in gconfd
Comment 1 Javier Uruen Val 2007-12-24 21:49:50 UTC 
Created attachment 101561 [details] [review]
patch against gconf 2.20.1 to unblock signals
Comment 2 Loïc Minier 2008-03-06 11:57:39 UTC 
Makes sense to me, this is part of daemonizing properly from a lib; could someone please ack the patch for commit?
Comment 3 Vincent Untz 2008-03-19 13:42:23 UTC 
Thanks. I went ahead and committed since there's no active maintainer right now.