For ages, Unix systems have booted by simply running an app called “init”, which in turn read shell scripts from
This is why on almost all Unix systems, every process would have as its ancestor process id 1, “init”.
it first showed up in last year’s release of Mac OS X 10.4 Tiger.
It replaces not only
init, but also
inet) So, now Ubuntu has released something called
which is an even more advanced startup mechanism.
Cribbing some text from the upstart page, here are some of the differences between upstart and launchd:
You can read more in the article about how if Apple had open sourced launchd sooner, Ubuntu would have simply upgraded launchd. I’m hoping Apple will move to upstart. We shall see.
Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:
Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by
- system startup,
- file modified or placed in queue directory,
- particular time (cron replacement),
- connection on a particular port (inetd replacement).
/etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need
/usrto be mounted would need to spin in a loop waiting for
/usrto be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event).