[ale] systemd or not

[Michael B. Trausch]

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>