[Gllug] GConfd

[Nix]

On 20 Sep 2011, Sanatan Rai uttered the following:

> On 20 September 2011 17:42, Nix <nix at esperi.org.uk> wrote:
>> On 20 Sep 2011, Sanatan Rai told this:
>>
>>> Hi all,
>>>    I notice that gconfd starts up on my machine even when I am not
>>> running anything using GNOME.
>>
>> That just means you started something using GNOME in the past: gconfd is
>> persistent and keeps running after its parent is dead.
>
>    Ok, I get that. I kill it after running somethng that needs it, eg geeqie.
> For example, it is running now. I killed that last copy around the time I sent
> the initial email, and I haven't started any GTK+/GNOME stuff since then.

I suspect something else needed it and you didn't notice. Even Emacs
sometimes starts one. I'm running one now and I'm a KDE user... it
doesn't use much memory and can usually be ignored.

>>>   Strangely, the processed is owned by my userid but its PPID is init,
>>> this really seems strange.
>>
>> This 'adoption' behaviour is a universally-applicable Unix thing (wired
>> into the kernel): init(8) adopts all processes whose parents die.
>
>     I see. Thanks for this, I didn't know this.
>
>     So this must be for child processes that trap the SIGHUP sent by the parent
> when it dies, right?

The SIGHUP is not sent by the death of the parent. It is sent in two
situations:

 - to session leaders (processes that have called setsid()) when the
   terminal disconnects, if and only if clocal is not set (see 'stty
   -a'). (clocal is almost certainly not set for you.)

 - to all processes in a session leader's foreground process group
   (in shell terms, that pipeline that has not been 'bg'ed) when
   the session leader terminates.

So session leaders don't always get it (e.g. they will never get it if
they have no controlling terminal), and children of session leaders
don't always get it either. Its purpose is not to signal parent death:
it is to signal terminal disconnection.

There is no reliable portable way to get a signal on parent death: you
have to call getppid() periodically. Since this is obviously appalling,
there is a nonportable Linux-specific scheme:
prctl(PR_SET_PDEATHSIG,...). (However, you almost always have to
implement polling too, for the sake of portability to lesser Unixes.)

(This stuff is all tied up with terminal control and signal handling,
which is a terrifying and arcane field, is now described in immense
detail both in Stevens's excellent _Advanced Programming in the Unix
Environment_, and in Michael Kerrisk's equally superb updating of it
_The Linux Programming Interface_. The former book used to be an
essential buy: these days, it's probably a bit outdated for most uses,
and Kerrisk's book is probably a better thing to go for. If you don't
learn anything from it, you either missed something or you are a great
wizard.)

(You have certainly read some of Kerrisk's work before... he maintains
the man-pages project, which is the source of a large proportion of the
core OS manpages on a modern Linux system.)

-- 
NULL && (void)
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug