SIGHUP gconfd (was Re: rpms/regexxer/devel regexxer.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2)

[Toshio Kuratomi]

On Thu, 2005-10-06 at 14:43 +0200, Michael Schwendt wrote:
> On Wed, 05 Oct 2005 20:38:23 -0700, Toshio Kuratomi wrote:
> 
> > > Hmm, okay, this tracks back to a private collection of RPM scriptlet
> > > hints by Toshio Kuratomi copied into the Wiki.
> > > 
> > > Mark McLoughlin from Red Hat commented on the GConf2 scriptlets on "Wed,
> > > 02 Mar 2005 08:59:48 +0000" on fedora-maintainers list in the following
> > > rather vague way:
> > > 
> > >     [...] and we should probably also be doing killall -HUP gconfd-2 or
> > >     something so the daemons see the new schemas.
> > > 
> > > Seeing the word "probably" and seeing that none of the packages installed
> > > on my Rawhide machine does this, I find it questionable.  This would
> > > signal *all* running gconfd-2 processes (also user's) to reload all
> > > databases. I don't like it when package installation "touches" user
> > > processes. 
> > 
> > The gconf daemon needs to refresh its knowledge of the schemas when
> > they're updated.
> 
> Is this a definite MUST or a SHOULD? Packages in Fedora Core don't send
> SIGHUP to all gconfd-2 processes. Hence the question.
> 
I've had instances where a package upgrade doesn't work the way I expect
because it did not get the new schema definitions.  However, it is a
subtle problem that an end-user might not notice most of the time.  Most
upgrades don't upgrade the schema.  When they do, a well coded program
is supposed to handle the case where no schema is defined.  It won't
always cause a problem for the whole program, just for the one
configuration value being strange.

I'd call it a MUST because it will eventually cause problems when
upgrading a package that defines new gconf values and is designed to
work this way so it doesn't cause harm.

> > Otherwise, opening up a program that's just been
> > updated with a different schema could run into problems. 
> 
> Does gconfd-2 load all schema files upon restart? Or does it load
> schema files only as needed?
> 
I _think_ it loads and caches as needed.  But you should look to Mark,
Havoc, or the source to confirm this.

> > The gconfd-2
> > process is run by a user, but its purpose is to supply configuration
> > information to a program.  The gconf daemon needs to be alerted to the
> > fact that the schemas have changed so it can reload them.
> > 
> > > This SIGHUP features is implemented since July 2004. Doesn't
> > > gconfd-2 have any other means of detecting database changes at run-time?
> > 
> > Not that I'm aware of.  Which is why it was added.  
> > 
> > Here's the discussion of adding the SIGHUP handling.
> >   http://mail.gnome.org/pipermail/gconf-list/2004-June/msg00016.html
> > Note that Havoc is quoted here stating that even sending SIGTERM should
> > be okay for the way gconfd-2 is designed.
> 
> That thread also mentions problems, such as consecutive SIGHUP signals
> sent by installation of multiple packages, 

The final patch submitted at the end resolves this.  The SIGHUP does not
spawn an immediate reload.  It schedules a reload for gconfd-2's
internal cleanup function to perform.  If you have multiple package
upgrades quickly sending SIGHUP, it will not schedule one reload for
each SIGHUP.
 
> as well as that an application
> must be restarted, too, to see the new values actually.
> 
Which the mentioned post points out is not a problem.  Running programs
should continue to use the old values.  New invocations should use the
new ones.

> > Debian is using this extensively with gconf using packages.  Here's a
> > link to a discussion of changes to their debhelper scriptlet, dh_gconf
> > http://lists.debian.org/debian-gtk-gnome/2004/06/msg00195.html
> > 
> > > If not, why doesn't gconftool-2 communicate with gconfd-2 upon
> > > installing/removing schema files?
> > 
> > You'll have to get a reply from Mark or Havoc on that one.  As a guess,
> > I'd think that gconftool-2 can be used by a normal user to install
> > schemas or modify the configuration values for the user only.  In that
> > situation, it has no business trying to convince all gconf's on the
> > system to reload their cache.
> 
> Could be done for --makefile-[un]install-rule with a uid check,
> couldn't it?

You'll have to see what Mark or Havoc think.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20051006/bbc337c5/attachment.sig>