site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Hi, - 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. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Oct 7, 2008, at 5:21 AM, Mario Emmenlauer wrote: 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: 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. This email sent to site_archiver@lists.apple.com