[ale] systemd or not

[Charles Shapiro]

Mike, this is real interesting.  I started out suspicious and hostile about
systemd, and the press didn't help.   Your posts are changing my mind.

-- CHS


On Sat, Sep 6, 2014 at 5:13 PM, Michael B. Trausch <mike at trausch.us> wrote:

> On 09/06/2014 04:27 PM, James Sumners wrote:
>
>> On Sat, Sep 6, 2014 at 2:22 PM, Michael B. Trausch <mike at trausch.us>
>> wrote:
>>
>>  Writing a Service unit file is easier, and controlling processes is
>>> simpler. How is systemd "in the way"?
>>>
>>> For lightdm:
>>>
>>> [Unit]
>>> Description=Light Display Manager
>>> Documentation=man:lightdm(1)
>>> Conflicts=getty at tty1.service
>>> After=systemd-user-sessions.service getty at tty1.service
>>> plymouth-quit.service livesys-late.service
>>>
>>> [Service]
>>> ExecStart=/usr/sbin/lightdm
>>> Restart=always
>>> IgnoreSIGPIPE=no
>>> BusName=org.freedesktop.DisplayManager
>>>
>>> [Install]
>>> Alias=display-manager.service
>>>
>>>  How is it in the way? For one, I have no clue what any of that even
>> means.
>>
>
> If you take a minute and read it line-by-line, it should pretty well make
> sense if you've managed UNIX systems for more than a little while.  Systemd
> doesn't introduce anything major in terms of fundamental concepts, it just
> introduces a set of newer, simpler ways to do what we did before so that we
> can make better use of our time.  (That's what technology is supposed to
> do, isn't it?)
>
> The structure requirements to write them can of course be learned by
> reading the documentation, which is pretty well-written.  Often, services
> are left alone; when they do need to be modified, you can typically do so
> by copying and modifying the file and the system simply honors it.
>
> The Description, Documentation, and After lines should pretty well make
> sense; the Conflicts line is there because systemd implementations often
> run the display manager on tty1.
>
> The [Service] section tells systemd how to manage or supervise the
> process.  ExecStart gives the command line, Restart tells systemd whether
> it needs to always restart, restart only if it died with an error, or never
> restart.  IgnoreSIGPIPE should be pretty obvious. The BusName line sets up
> systemd for *socket activation*, meaning that if the lightdm service is
> enabled (*systemctl enable lightdm.service*) but not currently running, and
> a D-Bus connection is made to the *org.freedesktop.DisplayManager* D-Bus
> endpoint, systemd will notice and spawn the display manager to answer it.
>
> Systemd supports services starting normally, as well as socket activation
> via UNIX socket, TCP socket, or D-Bus socket, or as the result of a hotplug
> event.
>
>  Two, when do they start? Under what run levels?
>>
>
> There is no concept of "run level".  Again, problem which can be fixed by
> reading the documentation and learning the system; it's not expected to be
> the same as an init system because it isn't an init system.  It is a system
> manager, which includes an init system.
>
> You have the concept instead of "targets".  For example, there is
> *default.target* and *graphical.target* and *multi-user.target*.  These can
> be loosely said to be like runlevels, but there are an arbitrary number of
> them.  If you want to define a *system-maintenance.target*, you can.  If
> you want to define a *system-thinks-its-compromised.target* which is
> configured to run programatically by a security system you have, guess
> what, you can.
>
> You /could/ do these things with an init system by modifying all the trees
> and reading script files, but that's way more difficult.
>
> systemd makes it possible to control every aspect of the system's
> management either at the system itself, or remotely, using any number of
> management utilities.  Among other reasons, because every file format is
> well-documented and not ad-hoc.  There are no shell scripts to manage the
> system.  The system provides a D-Bus interface for managing the services
> that are running, enabled, or disabled, as well as command-line utilities.
> Overall, this means that we can now programmatically manage entire fleets
> of systems without having to put together all of the components that would
> typically be required to do so.  Yes, you still need to configure your
> service configuration files, things like the database servers and display
> managers need to read their configuration.  But you can manage them in the
> same way as with "classic" init systems, by modifying files and using
> command lines, or you can manage them /any way you want/, from anywhere,
> over a secure SSH link and without a shell.
>
>    I could come up with
>> others, but, whatever.
>>
>
> If you come up with any that aren't the result of "I don't like change" or
> "I don't want to read the documentation" or similar, I'm not interested.
> However, if you come up with ways that systemd is actually "in the way", I
> am all ears.  For my part, having approached it a skeptic, and seeing
> first-hand what I can do with it in simply minutes as opposed to hours or
> days starting from scratch---five packages is the minimum system, no
> massive configuration required, it just works out of the box---and easy,
> simple, secure local and remote management?  I'm sold.
>
> Filesystems get more complex all the time; all modern filesystems resemble
> databases more than they do filesystems of decades gone by.  Filesystems of
> decades gone by could be interpreted by a human being by reading the raw
> disk blocks.  Now we must use tools to inspect and repair e.g., zfs, btrfs,
> NTFS, or ReiserFS.  People whined at the introduction of filesystems which
> were opaque to humans.  However, the things that these filesystems provide
> vastly outweigh the Old Dominion of relatively simple and linear
> filesystems, and that's why they're popular: They themselves are more
> complex, */but they simplify the system overall/*. And that's worthwhile,
> no matter whether you're a programmer or an administrator.
>
>     --- Mike
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.ale.org/pipermail/ale/attachments/
> 20140906/9278ae8b/attachment.html>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140906/1bd14a84/attachment.html>