<div dir="ltr"><div>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.<br><br></div>-- CHS<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 6, 2014 at 5:13 PM, Michael B. Trausch <span dir="ltr"><<a href="mailto:mike@trausch.us" target="_blank">mike@trausch.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/06/2014 04:27 PM, James Sumners wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, Sep 6, 2014 at 2:22 PM, Michael B. Trausch <<a href="mailto:mike@trausch.us" target="_blank">mike@trausch.us</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Writing a Service unit file is easier, and controlling processes is<br>
simpler. How is systemd "in the way"?<br>
<br>
For lightdm:<br>
<br>
[Unit]<br>
Description=Light Display Manager<br>
Documentation=man:lightdm(1)<br>
Conflicts=getty@tty1.service<br>
After=systemd-user-sessions.<u></u>service getty@tty1.service<br>
plymouth-quit.service livesys-late.service<br>
<br>
[Service]<br>
ExecStart=/usr/sbin/lightdm<br>
Restart=always<br>
IgnoreSIGPIPE=no<br>
BusName=org.freedesktop.<u></u>DisplayManager<br>
<br>
[Install]<br>
Alias=display-manager.service<br>
<br>
</blockquote>
How is it in the way? For one, I have no clue what any of that even means.<br>
</blockquote>
<br></span>
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 *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.<u></u>DisplayManager* 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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Two, when do they start? Under what run levels?<br>
</blockquote>
<br></span>
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 *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-<u></u>compromised.target* which is configured to run programatically by a security system you have, guess what, you can.<br>
<br>
You /could/ 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 /any way you want/, from anywhere, over a secure SSH link and without a shell.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I could come up with<br>
others, but, whatever.<br>
</blockquote>
<br></span>
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, */but they simplify the system overall/*. And that's worthwhile, no matter whether you're a programmer or an administrator.<br>
<br>
--- Mike<span class=""><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br></span>
URL: <<a href="http://mail.ale.org/pipermail/ale/attachments/20140906/9278ae8b/attachment.html" target="_blank">http://mail.ale.org/<u></u>pipermail/ale/attachments/<u></u>20140906/9278ae8b/attachment.<u></u>html</a>><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/<u></u>listinfo</a><br>
</div></div></blockquote></div><br></div>