Re: Controlling who is shutting down a daemon
Re: Controlling who is shutting down a daemon
- Subject: Re: Controlling who is shutting down a daemon
- From: Terry Lambert <email@hidden>
- Date: Tue, 09 Dec 2008 10:33:22 -0800
On Dec 9, 2008, at 6:54 AM, Tom Fortmann
<email@hidden> 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.
So yes, it's possible.
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.
-- 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