site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com So yes, it's possible. -- 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 Dec 9, 2008, at 6:54 AM, Tom Fortmann <tfortmann@xcapesolutions.net> wrote: Is there a way to determine and control who is shutting down a daemon? Our daemon is launched under launchd and is restarted by launchd if we crash, but I would like to limit the graceful shutdown to just launchd/launchctl. What I am trying to avoid is someone (or some process) with root authority issuing a shutdown signal to our pid. On a similar note, does anyone know if when the system is shutting down does launchd/launchctl shutdown the daemons, or is another process used to kill the running daemons? In older systems, the process teardown is implemented interior to the reboot system call, which is normally called by launchd. In current systems, it's implemented in launchd itself. Each process us sent SIGTERM and given the opportunity to gracefully exit; if it can't do so in a reasonable time, the process is sent a SIGKILL. If that doesn't work (for example, the TH_UNINT bit is set and it's blocks in some uninterruptible part of Mach), its address space and threads are manually disassembled, rather like being eaten by Pirahnah. SIGKILL is not catchable or blockable, period, so long as it's possible to call thread_abort() on a Mach thread. So in terms of graceful shudowns, I have to guess you are talking about SIGHUP and SIGTERM. Realizing that launchctl uses a framework which is supposed to be available to third parties to talk to launchd, just as launchctl itself does, and therefore there are legitimate cases where some other program could validly shut you down, that should come in via launchd these days. In your SIGTERM handler, which you will establish by calling sigaction () instead of signal(), and for which you will specify the SA_SIGINFO flag to the sigaction structure, you can look at the si_pid field of the siginfo_t at the time of the signal to identify the sending process and therefore distinguish between a signal set to you as a result of a genuine machine exception vs. one sent on purpose by another process, and whether or not that process was launchd or something else. This is likely too restrictive in general, given per-session launchds as well. You will likely (if your daemon is written correctly) want to permit *either* PID 1 (the system launchd) *or* any process matching getppid () to send you the signal, to allow for things like common debugging cases. Additionally, if you are going to effectively ignore signals sent by other people, minimal politeness (and culprit identification) would have you log "unauthorized" signals sent to your process, the sending PID, the fact that the signal was discarded, and why it your process considered the discard justified. You may also want to include "here's how you shut me down gracefully" in the logged information. Personally, I reccomend against doing these types of checks; if something like this is happening, then the sender is not going to stop at SIGTERM (they want you gone), and launchd will be restarting you anyway, until it's informed not to, so other than stopping and restarting, there's no harm in letting it happen, at least for daemons who already drank the launchd koolaide. In general, if at all possible, machines should do what people tell them to do, even if it's a dumb thing, as long as there is no lasting harm. This email sent to site_archiver@lists.apple.com