<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/06/2014 04:27 PM, James Sumners
wrote:<br>
</div>
<blockquote
cite="mid:CAAt=rgDAujckZfFJQa194ou8Kkm_teNPakKCaept7RxrRqV1rw@mail.gmail.com"
type="cite">
<pre wrap="">On Sat, Sep 6, 2014 at 2:22 PM, Michael B. Trausch <a class="moz-txt-link-rfc2396E" href="mailto:mike@trausch.us"><mike@trausch.us></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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=<a class="moz-txt-link-freetext" href="man:lightdm(1)">man:lightdm(1)</a>
<a class="moz-txt-link-abbreviated" href="mailto:Conflicts=getty@tty1.service">Conflicts=getty@tty1.service</a>
After=systemd-user-sessions.service <a class="moz-txt-link-abbreviated" href="mailto:getty@tty1.service">getty@tty1.service</a>
plymouth-quit.service livesys-late.service
[Service]
ExecStart=/usr/sbin/lightdm
Restart=always
IgnoreSIGPIPE=no
BusName=org.freedesktop.DisplayManager
[Install]
Alias=display-manager.service
</pre>
</blockquote>
<pre wrap="">
How is it in the way? For one, I have no clue what any of that even means.</pre>
</blockquote>
<br>
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?)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 <b>socket activation</b>,
meaning that if the lightdm service is enabled (<b>systemctl enable
lightdm.service</b>) but not currently running, and a D-Bus
connection is made to the <b>org.freedesktop.DisplayManager</b>
D-Bus endpoint, systemd will notice and spawn the display manager to
answer it.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAAt=rgDAujckZfFJQa194ou8Kkm_teNPakKCaept7RxrRqV1rw@mail.gmail.com"
type="cite">
<pre wrap="">
Two, when do they start? Under what run levels?</pre>
</blockquote>
<br>
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.<br>
<br>
You have the concept instead of "targets". For example, there is <b>default.target</b>
and <b>graphical.target</b> and <b>multi-user.target</b>. These
can be loosely said to be like runlevels, but there are an arbitrary
number of them. If you want to define a <b>system-maintenance.target</b>,
you can. If you want to define a <b>system-thinks-its-compromised.target</b>
which is configured to run programatically by a security system you
have, guess what, you can.<br>
<br>
You <i>could</i> do these things with an init system by modifying
all the trees and reading script files, but that's way more
difficult.<br>
<br>
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 <i>any way you want</i>,
from anywhere, over a secure SSH link and without a shell.<br>
<br>
<blockquote
cite="mid:CAAt=rgDAujckZfFJQa194ou8Kkm_teNPakKCaept7RxrRqV1rw@mail.gmail.com"
type="cite">
<pre wrap=""> I could come up with
others, but, whatever.
</pre>
</blockquote>
<br>
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.<br>
<br>
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, <b><i>but they simplify the system overall</i></b>.
And that's worthwhile, no matter whether you're a programmer or an
administrator.<br>
<br>
— Mike<br>
</body>
</html>