[launchd-dev] early boot hook in launchd/launchctl?
Greg Shenaut
gkshenaut at ucdavis.edu
Tue Jun 23 18:20:56 PDT 2009
Until recently, it was possible to put arbitrary code into /etc/
rc.server to perform scripted maintenance activities in the early boot
context (i.e., system disk still write-only, limited driver access,
etc). In the version distributed with 10.5.7, rc.server shows up later
in the sequence (i.e., system disk mounted read-write). In any case,
adding code to rc.server always was a kludge.
Now, the cleanest way to do it seems to be to put code into /.env and
use "nvram boot-args=-s ; reboot" to run it. This is actually a much
cooler kludge, because /.env (the value of ENV in single-user mode) is
normally run only in single-user mode, because otherwise the HOME
variable will be set, and for root that will cause ENV normally to be
defined as /var/root/.env. Because /.env only gets run in single-user
mode, you can put in fairly elaborate checks to make sure you're in in
the right place without negatively impacting startup time for normal
root shell scripts.
But I'm concerned that this method, like rc.server, will someday be
seen by the launchd developers as a bug (that is, HOME not being
defined in single-user mode); in this case, it too will suddenly
disappear and some other kludge will have to be found.
So what I'm wondering is whether it might not be a good idea to
provide a conventional hook for early-boot maintenance. It could
simply be a shell script in a standard location such as /etc/
rc.earlyboot which gets executed by launchd if present, owned by root,
and not writable except by root. This would keep people who insist on
doing this kind of thing from having to keep finding new and better
kludges.
Or, of course, the /.env thing and the HOME-less single-user shell
could become a feature of launchd that is reserved for this purpose.
Thank you,
Greg Shenaut
More information about the launchd-dev
mailing list