Systemd Sucks, Long Live Systemd

At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it&#x27;s problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux&#x2F;systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion.<p>But having used a couple of Linux systems running systemd - Raspian Jessie and openSUSE - I have to admit it&#x27;s not that bad. In practice - on laptops and desktop systems (assuming one counts the Pi as a desktop system; for my use case, I do) - I had no problems with it. Enabling and disabling services is a lot easier. I do not think is as great as its proponents claim, but it&#x27;s not as bad as some people think, either. Personally, I have come to appreciate journald, even though I still agree that binary logs are a bad idea. At least there is still the option of installing a syslog daemon.

I&#x27;d probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo&#x27;s OpenRC instead of pretending it&#x27;s invented dependency handling.<p><a href="https:&#x2F;&#x2F;wiki.gentoo.org&#x2F;wiki&#x2F;Comparison_of_init_systems" rel="nofollow">https:&#x2F;&#x2F;wiki.gentoo.org&#x2F;wiki&#x2F;Comparison_of_init_systems</a><p>&gt; OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

&gt; The justification for storing logs in a binary format was speed and performance, they are more easily indexed and faster to search.<p>Are there any benchmarks for this? I don&#x27;t know why, and I may be doing things wrong, but journalctl -lu &lt;unit&gt; --since yesterday in our prod env takes a couple of seconds before I see any output, while a (z)grep on a date rotated, potentially compressed log file on a non-journald system is generally instantaneous.<p>On a side note, I really like machine parsable, human readable logs, and I&#x27;ve never had any speed or performance issues with it when dealing with volumes of hundreds of millions of log entries, though that may be because I don&#x27;t know any better.

At first I didn&#x27;t care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it was kind of required that I have some basic understanding of systemd. I have to say now that I&#x27;m more familiar with it it has begun to grow on me.<p>There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what the current state of services are on a system, being able to control the life cycle of a service including having systemd monitor and restart it, not having to deal with improperly written init scripts, etc.<p>Stockholm Syndrome perhaps?

Best thing of systemd is that it&#x27;s putting people behind alternate systemd-free Linuxen. Devuan, Alpine, Gentoo, Void (and particularly the BSDs) come along nicely.<p>I can tolerate systemd on desktops as long as I don&#x27;t have to deal with it. The moment it craps out with Java-esque error traces in binary logs I&#x27;ll install Slackware (or is there a modern desktop Linux without systemd I&#x27;m not aware of?).<p>Other than for desktops with complex run-time dependencies (WLAN, USB devices, login sessions), what are the benefits of systemd for servers that warrant a massive, polarizing, tasteless monolith which puts you up for endless patches and reboots, especially in a container world? (Re-)starting and stopping a daemon isn&#x27;t rocket science; it&#x27;s like 10 lines of shell code.

I&#x27;ll put my opinion in the middle ground with systemd as well. I like a lot about it, and I dislike a lot about it. I really think the best thing they could have done would have been to make it modular. If people could just turn off the &quot;features&quot; that they don&#x27;t want, there wouldn&#x27;t be so much bitching about it.<p>Instead they keep trying to shove everything into one giant pile, and don&#x27;t understand why people get upset.

Personally, I love Systemd for Web development as it makes the job of managing Node.js projects a breeze. I simply pack a Systemd unit file into a project&#x27;s repository as part of its multi-environment configuration and construct deployment tasks to copy, enable, then start the unit file.<p>1. Copy &lt;unit.service&gt; to the sever, which looks like:<p><pre><code> [Unit] Description=&lt;name&gt; Service After=network.target [Service] Restart=always StandardOutput=syslog StandardError=syslog SyslogIdentifier=node-&lt;name&gt; User=&lt;user&gt; Group=&lt;group&gt; WorkingDirectory=&#x2F;srv&#x2F;node&#x2F;&lt;name&gt;&#x2F;current&#x2F; Environment=&quot;NODE_ENV=production&quot; Environment=&quot;PORT=2580&quot; ExecStart=&#x2F;usr&#x2F;bin&#x2F;node server.js [Install] WantedBy=multi-user.target </code></pre> 2. Enable the unit file in place:<p><pre><code> sudo systemctl enable &#x2F;srv&#x2F;node&#x2F;&lt;name&gt;&#x2F;config&#x2F;&lt;unit.service&gt; </code></pre> 3. Start the unit file:<p><pre><code> sudo systemctl start &lt;unit.service&gt; </code></pre> And, of course, destroying that deployment is just as easy.

Systemd ideas I&#x27;m all for but it only hints at linux lack of clean abstraction power. sysvinit was full of redundancy; apparently BSD found a way to make a thin abstraction layer to make init files clean.<p>Bash isn&#x27;t &quot;good&quot; at hinting proper abstractions, I rarely see talks about this, maybe gurus can see through the rain.<p>I keep seeing a place for a tiny lambda friendly intermediate layer .. Just so you can compose properties of your services like clojure ring middleware.<p><pre><code> (-&gt; (path &quot;&#x2F;usr&#x2F;bin&#x2F;some-service&quot; &quot;arg0&quot; ...) (wrap :pre (lambda () ...) :post (lambda () ..)) (retry 5) ... (timeout 5)) </code></pre> Is this ugly to your eyes ?<p>ps: the idea is that (retry 5) is a normal language function, and not a systemd opaque built-in, you can write your own thing, and the most used can go upstream. Hoping to avoid the sysvinit fragility and redundancy.

I feel like at some point, news aggregation sites will need moratoriums on this topic. Systemd is an architectural decision with very philosophical effects, so by its very nature be very divisive. I&#x27;m, personally, not a fan at all of systemd, but am tired of seeing these stupid arguments everywhere all the time.<p>There are plenty of places to find competent summaries of both the technical and political arguments for and against systemd and we don&#x27;t need yet another.

Why would you run the Exec command through systemd-escape? The help text says that&#x27;s for the NAME of the unit... Am I missing something?<p>Also, I&#x27;m failing to think of a scripting purpose that requires you to place non-trivial bash directly in a systemd unit that couldn&#x27;t be solved by writing out the script somewhere and just invoking the script in the unit.

I don&#x27;t know if I&#x27;m just crazy but I did enjoy working with upstart for the brief time that I did, much more so than systemd or initv.

The problem with systemd is not that it is &quot;bad&quot;. There&#x27;s a lot worse software out there. Systemd is relatively competently programmed. And it&#x27;s even useful!<p>The problem with systemd has <i>always</i> been that it forces you to do everything the systemd way, and usually to use its tools. It goes against everything that has helped GNU&#x2F;Linux become a great system: that it wasn&#x27;t really one system. It was bits and pieces, and you could add them together however you wanted to get something you liked.<p>Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn&#x27;t follow any of the old conventions that made it simple to combine one tool with another. I can compare it to Windows, but I feel like that would be an insult to Windows&#x27; usability.<p>If this one single fact was different, everyone would love systemd, because it has plenty of useful features. But because it is designed specifically to please a single quirky user, people hate it.

I don&#x27;t care for SystemD for the same reasons that I don&#x27;t like MacOS&#x27;s init system: it an opaque, confusing mess.

Systemd has a lot of attention and people working on it and it will eventually become good enough for the vast majority.<p>But there were questionable tie-ins with various pieces like udev, consolekit and even gnome that allowed Systemd to become defacto init. The call for a kernel bus promotes a similar lock in with Systemd and this makes the use or development of alternatives and choice difficult.<p>There are things like predictable network names which are useful for 1% of users and are anything but predictable. Binary logging makes sense for the security industry Redhat serves but again has no use for the 99% others who anyway have to put up with it. There is a pattern of forcing things onto everyone that make sense for a tiny minority.<p>The big problem is open source funding. No one is interested in just supporting projects they benefit from. Acquisitions or hiring developers put these projects and developers under the control of companies like Redhat. Redhat has become a cathedral and a cathedral by sheer size and nature is always interested in securing and furthering its own influence and interests. When you allow such forces to become too powerful they will subsume the public interest to their interest.

The sad thing is, you do not really have a second option, yes I know some distros say they have alternatives, but SystemD becomes the &quot;preferred&quot; init system nearly everywhere now.<p>I just hope Debian to get rid of SystemD and return to whatever else. I know I&#x27;m biased, just failed to find a reason to love SystemD, tried a few times.

More and more systemd is becoming symptomatic of deeper divide within the Linux &quot;community&quot;.<p>The split being between those that embraced Linux for being a free, in both senses, _nix unburdened by AT&amp;T and running on commodity hardware, and those that got to know it after the dot-com crash as the L in LAMP.<p>The former cares for Linux as a _nix, the latter could not care less about _nix and may see it as a vestigial appendage that should have been amputated long ago.

I&#x27;ve never particularly liked init systems that restart jobs when they die. Normally, I don&#x27;t want daemons that crash to restart. They should die, be caught by monitoring and the server bypassed. I would accept a single restart but after that, there&#x27;s clearly a problem, and the systems should fail, rather than restarting the process again and again and again.

One of the things I like about systemd is you can get a graph of the boot time along with critical path via the following: systemd-analyze plot &gt;boot.svg

&gt; Admittedly, it requires an environment file<p>I know almost nothing about systemd, but you can define environment variables inline instead of in a file: `Environment=ENV_VAR=value`.

Most people I hear having problems with Systems is either on Redhat or Debian - not realising the both are mangling systemd badly. RHEL took in systemd way too early and are missing a lot of needed functionality. Also the have an ungodly amount of patches on top - so much you could argue it should be named redhatd instead. Debian just chooses to take the worst possible middle position due to politics. All of the disadvantages from systemd, but not really any of the great stuff as systemd units often just start shellscripts due to compatibility.... If you want to try systemd in all its glory try Arch or something downstream from it... I for one think that systemd has made my admin-life so much better ..

(from tfa): &quot;Now, let us turn our attention to the benefits that systemd brings us. I believe that these are the reasons that all Linux distributions have adopted systemd.&quot;<p><i>ahem</i> slackware has not adopted systemd

I&#x27;ve found runit to be the best (but not perfect) as far as init systems go. Check it out.

Yet another systemd post which<p>- Handwaves real criticisms and instead tries to look like an objective writing by presenting a trivial issue<p>- Have no idea about advances in sysvinit in the last decade that allowed support for parallel boot and dependency relations (and which was supported natively on mainstream distribution)<p>- Totally ignores the other &quot;modern&quot; and <i>widely</i> used init system and instead compares systemd with sysvinit of 80&#x27;s (which wasn&#x27;t used by any mainstream distro in that form)<p>- Overrates process supervision features which were already as equally as easy to use with supervision suites like runit (IMHO even easier)<p>Meh, what did I expect? Bandwagon is going full speed.

My main complain about systemd is that it does not log the stderr stream !!

Does systemd have a network protocol like syslog, i.e. is there a native way to send logs for a particular unit&#x2F;service to a remote machine?<p>Everything I find just says to install syslog, which surprises me.

I get the feeling anyone who complains about systemd is just a hobbyist jumping on a hate bandwagon. For anyone who manages production systems, systemd is a godsend compared to the homegrown-per-distro shell based init systems.