Linux command comparison
Blake Barnett
shadoi at nanovoid.com
Fri Dec 8 11:40:44 MST 2006
On Dec 8, 2006, at 8:48 AM, Michael Torrie wrote:
> On Fri, 2006-12-08 at 06:56 -0700, Hans Fugal wrote:
>> I heartily agree, although it bears mentioning that some distros are
>> making the long-overdue migration away from System V init schemes
>> (the
>> symlinks in /etc/rc.d or similar places) to something better. e.g.
>> Ubunutu is using upstart, which looks very cool, and Debian has
>> optional
>> support for upstart and other systems like runit.
>
> For a desktop distro this is probably a good idea, but for servers,
> nothing beats System V in my opinion. Having well-defined custom
> runlevels (something most of us probably should do but don't)
> allows for
> much better system administration. For example, if your server
> applications are layered, you can use runlevels to add layers in a
> controlled fashion. Runlevel 5 could be everything up full, and
> runlevel 4 could be everything but the web interface, runlevel 3 could
> be just the sql server running, and runlevel 2 could be standard
> multi-user, network, but the apps are shut down for maintenance.
>
> Having messed with Tiger's new LaunchDaemon, I can see some definitely
> benefits to it over the older pseudo-rc system. But it seems to not
> have any real concept of runlevels, although there Mac does support a
> single-user mode, so I don't know how it fits in.
launchd doesn't do runlevels, it's mostly designed with the desktop
in mind, and so usually prefers to load things ondemand. But it can
support dependencies, the WatchPaths and QueueDirectories can be used
to enforce the order that things load up. And in a lot of ways, it's
more reliable than init scripts because you can ensure that a service
does not attempt to load until it's dependencies have fully loaded
and written the file that launchd is watching for. It's quite
different, but all the other features of launchd are well worth
adjusting to. (Even though I usually hate XML config files)
-Blake
More information about the PLUG
mailing list