why do we use systemd?

[Garry T. Williams]

On 7-6-14 00:58:23 Patrick O'Callaghan wrote:
> To go back to the same example as before, the concept of "unit"
> seems to me not well-defined. The man page says a unit is an object,

systemd(1) states:

    CONCEPTS
	   systemd provides a dependency system between various
	   entities called "units" of 12 different types.  Units
	   encapsulate various objects that are relevant for system
	   boot-up and maintenance.  The majority of units are
	   configured in unit configuration files, whose syntax and
	   basic set of options is described in systemd.unit(5),
	   however some are created automatically from other
	   configuration, dynamically from system state or
	   programmatically at runtime. Units may be "active" (meaning
	   started, bound, plugged in, ..., depending on the unit
	   type, see below), or "inactive" (meaning stopped, unbound,
	   unplugged, ...), as well as in the process of being
	   activated or deactivated, i.e. between the two states
	   (these states are called "activating", "deactivating"). A
	   special "failed" state is available as well, which is very
	   similar to "inactive" and is entered when the service
	   failed in some way (process returned error code on exit, or
	   crashed, or an operation timed out). If this state is
	   entered, the cause will be logged, for later reference.
	   Note that the various unit types may have a number of
	   additional substates, which are mapped to the five
	   generalized unit states described here.

> but then it talks about various types of units, some of which are
> associated with events,

Perhaps you mean Timer units?  Or maybe you mean Device units?

> others with sets of processes,

Target units?  Or maybe you mean just the common Service unit?

> others with
> system states,

I cannot guess what you mean here?

> while still others are recursively sets of other
> units.

Target.

> This seems to me symptomatic of a lot of technical
> documentation, i.e. the author knows what he's talking about but
> doesn't appreciate the need to get the reader to understand it. At
> certain points I find myself wondering if he actually meant to say
> "objective" rather than "object",

The systemd(1) manual page uses the term "entity" -- not object to
refer to units.  And it says units encapsulate various objects.
Perhaps this is the source of confusion?

> but that wouldn't fit either.
> Since the concept of unit appears to be basic to understanding what
> systemd is all about, this is a serious deficiency IMHO.

Right after the paragraph I quoted above, the manual page lists the 12
unit types along with a short description of each one *and* a link to
its own manual page.

The simple concrete example is a Service unit for a daemon.  I wrote a
daemon to work around a bug in the kernel that disabled my laptop's
backlight control.  I needed the daemon to start at boot and stop at
shutdown.  My unit file (encapsulating the requirements for my little
daemon) is:

    [Unit]
    Description = Enable Backlight Control

    [Service]
    ExecStart = /usr/local/bin/backlight
    Restart = always

    [Install]
    WantedBy = multi-user.target

This tells systemd what program to start and when it should be
started.  The declarative language for unit files is described in the
manual pages and encompasses a rich set of operators to express
complex dependencies.  I needed only one: my daemon must be started
whenever systemd determines that the multi-user Target is its
objective.  This corresponds to what we used to call system level 2.
My standard Fedora 20 installation on my laptop defines
graphical.target as the default.target.  That is, my normal boot
sequence is into the desktop.  That target, in turn, Requires and is
ordered After multi-user.target.

See systemd.service(5) and systemd.target(5).

One more step is required to actually get the daemon to start at boot-
time: the unit has to be enabled.  This just symlinks the unit file to
the multi-user.target.wants directory.  (See systemctl(1) for an
explanation of enable versus start.)  This may be what you referred to
as units that "are recursively sets of other units."

The analogy is placing a script in /etc/init.d and then linking its
name in the /etc/rc5.d directory.  Until you create a link in the
rc5.d directory, the script will not be executed during boot-up.  With
systemd, we don't have to *name* the symlink in a way to define the
ordering we want.  All of the dependencies are expressed in the unit
files defining the units and systemd creates a run queue that respects
these dependencies.

I find this much simpler than the sysvinit schemes.  Plus, we now have
the ability to declare dependencies instead of prescribe ordering.  Of
course my example is drop-dead simple in either world, but systemd
allows way more expressive power than this example.  The nice thing
is, you don't have to write code (shell scripts) to get what you need.

You might want to examine sshd.service in /usr/lib/systemd/system to
see a slightly more complex setup.  (Ignore the deprecated
After=syslog.target dependency.)

Yes, this is all very different from sysvinit.  But the documentation
is more than adequate.

-- 
Garry T. Williams