Re: daemon-child dies on user lougout
Re: daemon-child dies on user lougout
- Subject: Re: daemon-child dies on user lougout
- From: Terry Lambert <email@hidden>
- Date: Wed, 8 Oct 2008 10:54:15 -0700
On Oct 7, 2008, at 5:21 AM, Mario Emmenlauer wrote:
Hi,
I'm picking up on a thread called 'launchd daemon, spawning
children?'.
Terry Lambert wrote:
On Oct 1, 2008, at 3:40 AM, Mario Emmenlauer wrote:
One last question: If "worker_user" is the current GUI-user, all his
applications get killed on logout. Is there a way around this (or
would
using 'login' also solve this issue?)
The logout operation for non-GUI applications sends either a SIGHUP
(the correct signal), or a SIGTERM (not the correct signal). You
can ignore or catch these signals with a signal handler, although
if you ignore SIGTERM, you will delay shutdowns.
In general, daemons running as that user are not kiplled unless
they are in the process group, or their parent is the per-session
launchd. Otherwise, you would not be able to ssh into a machine
and log out of a GUI and not have it kill your ssh (which it
doesn't do).
Seems only logical. But I have an odd behavior there, my application
dies
on user-logout. Here is the scenario:
- daemon is running as root
- daemon fork()s a child, that setuid()s to some user
- child exec()s some worker program
- worker connects on a socket to the daemon, using ICE (www.zeroc.com)
- if the worker runs as current GUI user, and that user logs out, the
worker dies/crashes.
- if the worker runs as any other system user, all works fine.
ReportCrash saves a report similar to the one attached. The only
thing my
child and server are doing are the network connection, and some disk
usage.
When I use a dummy worker that does nothing (sleeps), it doesn't die
(and
gets no SIGTERM or SIGHUP sent, as Terry already predicted).
So I can only imagine that the logout kills the ICE socket
connection for
that user? Does that make any sense to anyone?
The most likely scenario is that the process running in the background
sets up some UI component or another as a result of the framework(s)
it is using under the covers, and as a result, ends up becoming
dependent on the WindowServer; when the user logs out, that goes away
and the process ends up shutting down for lack of the dependency.
Without knowing exactly all of the communications channel resources
(workloops, sockets, mach ports, ptys, pipes, named pipes, etc.) being
used by the process, and what's on the other end of those channel
resources, it's rather hard to diagnose something like this remotely.
Your best bet would be to start small; I imagine a very simple program
that did a "while(1) sleep(1000);" would not have this problem. Add
things back in until it starts exhibiting the behaviour, and you'll
have found your culprit.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden