On Jan 13, 2012, at 8:27 AM, Matt Burgess wrote: > I like the idea behind systemd, inasmuch as they are trying to speed > booting up by using dependencies to allow scripts to run in parallel > rather than Sysvinit's serial boot ordering.
Parallelization and the related speed is one of the talking points, and for
some people that's important, but IMHO it's not the reason we, as system
builders and admins, should care.
Systemd provides a number of other benefits including:
1. All daemons are first-class citizens that get monitoring and re-launching.
Sysvinit theoretically provides monitoring, but since it doesn't provide an
easy way to enable/disable services in practice most people only launch really
vital, never-down services with it. And with the use of cgroups to capture
processes systemd provides much better monitoring that sysvinit or even many
purpose-built tools (e.g. it can track even through a double-fork).
2. There is no need to manually order the launch of daemons. Just specify the
service(s) they require, if any, and let the system figure it out for you. Also
no need for huge, mostly redundant symlink directories to tell your boot
scripts what to do.
3. Unlimited number of named configuration sets, and snapshots. It's not
necessary to wedge your usage into 5 numbered configuration sets, or to provide
instructions on how to switch between them; just identify what should run in a
given target, either explicitly or relative to another target.
4. Useful disk and boot-time events and handlers. For example, systemd provides
a useful way to deal with encrypted mounts that might be necessary for certain
services, but that require human interaction to mount (or that might need a
manual fsck or the like). It will block only the affected service(s) (with an
interruptible sleep), monitor for the mount to become available, and
immediately unblock the service when the mount becomes available.
5. Avoids use of the shell. Sometimes it's necessary to use a shell to setup a
process, but frequently it's not, and there's a lot over overhead involved if
all you really need to do is exec a binary and keep track of it's process(es).
6. Socket services. Back in the day we had inetd, which allowed you to listen
for connections without actually running all the different deamons. systemd
provides the same concept, but for UNIX sockets and D-Bus connections. So
rarely-used services can launch on demand rather than at boot (think printing,
for example). There are also parallelization/dependency implications to this
concept; you need not make service A depend on service B if service A only
needs to access service B's socket -- you can freely launch A and when it
attempts to access B's socket systemd will queue that request until B is
available (starting B if necessary).
--
That being said, I think it's prudent to wait until systemd itself is stable
and at least somewhat widely used; the concept of systemd or a similar sysvinit
replaces seems inevitable to me, but I agree that it's not yet clear that
systemd, in its current incarnation, will be that replacement.
Also if we wait until it's in wider use it will not be necessary to write all
our own startup config for LFS/BLFS daemons, which would be handy. It's also
likely that, at least within a distro (and hopefully across them) there will be
some naming standards that make systemd configs fairly interchangeable, and it
would be nice to adopt those.
Zach
smime.p7s
Description: S/MIME cryptographic signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
