This is an old revision of the document!


systemd: Denial or just alternative ways?

We are surely aware about the criticism towards systemd as project. But this article should not only be focussed onto that and be therefore more oriented towards our reasoning for a system beyond using only bloated packages and frameworks. So we could now list for sure many reasons why we stay critical towards the adaption for systemd as basic init-framework, but we want to provide a complete picture.

Systemd denial

Obarun compromises neither principles nor finctionality!

I feel like I have found a real hidden gem with Obarun.

I'm not a huge fan of SystemD, not because it's slow or anything, mostly ideological reasons. Plus I find Distributions that choose no to use it make other choices I like, such as being more minimalistic.

I went to through great efforts trying to remove SystemD completely from Gentoo (as you may be aware, it uses elogind and quite a bit of SystemD code even when using OpenEC as init). I got it done, sure, but at the cost ofba great deal of functionality. No elogind, no steam or firefox for you!

So down the rabbit hole, finding out most supposedly systemd free distros use great quantities of SystemD code. Very disappointing, why bother avoiding SystemD if you aren't going to follow through?

I find a lot of Distros that go the extra mile, but seems very difficult may be accused of being “memes” such as Kiss linux and whatnot. They look quite fun, but i need something less alien.

I stumble upon Obarun. The Arch base is comforting since I know Arch well, and s6 is intriguing. No SystemD nonsense whatsoever! I try it instantly! Some growing pains, s6 is pretty tricky compared to others.

22nd June 2018: Renaming Network Interfaces.</h3> <div class=“col-lg-10 col-lg-offset-1 text-left”> <p> As announced in the systemd mailing list, <a href=“https://lwn.net/Articles/758128/” target=“_blank” rel=“nofollow”>version 239 of systemd will name network interfaces differently than in previous versions</a>.</p> <p>Because breaking the name of my network adapter is exactly what I was asking for.</p> <p>There are a whole set of other changes in the same announcement which should make it clear to any sane person contemplating switching over to this system that it is not yet ready for production use. The definitions of blacklist/whitelist have swapped over; a hibernate update notes that “swap files should work for hibernation now.” - because it's absolutely fine to “support” hibernation for years, for 239 releases, without hibernation actually, well, working

https://pwnies.com/winners/“>pwnie awards</a> awarded systemd its “Lamest Vendor” prize in 2017, due to its handling of bugs <a target=“_blank” rel=“nofollow” href=“https://github.com/systemd/systemd/issues/5998”>5998</a>, <a target=“_blank” rel=“nofollow” href=“https://github.com/systemd/systemd/issues/6225”>6225</a>, <a target=“_blank” rel=“nofollow” href=“https://github.com/systemd/systemd/issues/6214”>6214</a>, <a target=“_blank” rel=“nofollow” href=“https://github.com/systemd/systemd/issues/5144”>5144</a>, and <a target=“_blank” rel=“nofollow” href=“https://github.com/systemd/systemd/issues/6237”>6237</a>. The Register <a target=“_blank” rel=“nofollow” href=“https://www.theregister.co.uk/2017/07/28/black_hat_pwnie_awards/”>has more details</a>.</p> </div> </div> <!– /row –>

<div class=“row” id=“dynamicusers”><h3>Dynamic Users</h3><div class=“col-lg-10 col-lg-offset-1 text-left”> <p>Dynamic Users is a feature added between v232 and v235 of systemd. There's a <a target=“_blank” rel=“nofollow” href=“http://0pointer.net/blog/dynamic-users-with-systemd.html”</a>blog post by Poettering here</a>.</p> <p>What is a Dynamic User, you ask?</p> <p>Well, it's a system account which is created when the service starts, and is deleted, along with all the files owned by that user, when it stops. And yeah, that's about as stupid and dangerous as you might imagine it to be. It claims that it avoids the “problem” (have you ever encountered this problem?) with the numerical limit on available UIDs and GIDs, yet it also allows for persistent directories - you know, just in case you wanted your data to still be there after you've restarted the service! (some people are *so* fussy about actually *keeping* their data, I don't know!).</p> <p>But it keeps them hidden under “chmod 0700” root-owned directories. Then they realised that if you start the service up again, and another process has taken your previous UID, then they'll have to do a recursive “chown -R” on your data, so you'll just have to wait for that to complete before you can start the task of actually starting up your application. Heaven forbid it'd be a large amount of data, or on a slow, or read-only, or remote media such as NFS.</p> <p>Given systemd's history in terms of security and protection of user data (that is, the designers simply don't care about such things), it will only be a matter of time (<B>the blog post above was 6/10/17; this rant was written on 17/10/17; I'll try to remember to update this piece when I hear of the first example of inadvertent data loss or exposure caused by systemd as soon as I hear of it</b>) until this implementation loses somebody their data. That is, if anybody is stupid enough to make use of this “feature” in the first place. Which does seem unlikely, since it's solving a problem that nobody has ever reported. Ever.</p>

DNS</h3><div class=“col-lg-10 col-lg-offset-1 text-left”>

<p><a target=“_blank” href=“https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-15908”>CVE 2017-15908</a> has the full details, and you can read a bit more in plain-English <a target=“_blank” rel=“nofollow” href=“https://usn.ubuntu.com/usn/usn-3466-1/”>from Ubuntu</a>, but in a nutshell: a given DNS response (so far, I believe, the details have not been made public) will cause systemd to hang entirely. So a total Denial of Service (DoS) attack on your ability to manage your system.</p> <p>Wow - nobody ever warned that there was a massive danger inherent in putting so much arbitrary code into

PID 1

, did they?</p> <p>Oh, wait. They did. Yes. Absolutely everybody did warn them about this huge, monolithic, unwieldly

PID 1

process taking control of so may existing subsystems, with the potential for new bugs in any one of them to affect the stability of the entire system. Many times. We did that. But systemd rolled on anyway. And broke a lot of systems for a lot of people.

https://ewontfix.com/14/ https://suckless.org/sucks/systemd/ https://the-world-after-systemd.ungleich.ch/

	<h2>What is so bad about systemd?</h2>
	<p>List of notable bugs and security issues:</p>
	<ul>
		<li><a href="https://github.com/systemd/systemd/issues/437">#437: timeX.google.com provide non standard time</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/1143">#1143: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/1312">#1312: restarting systemd service on dependency failure</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/1596">#1596: journalctl -r -n flags incorrectly processed</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/2402">#2402: Mount efivarfs read-only</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/2460">#2460: Showing status of service via systemctl is slow (>10s) if disk journal is used</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/4863">#4863: systemd-journald drops all bytes after '\0'</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/5644">#5644: tmpfiles: R! /dir/.* destroys root</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/6237">#6237: systemd can't handle the process previlege that belongs to user name startswith number, such as 0day</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/6369">#6369: hostnamed does not like fqdns with trailing dots</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/6381">#6381: systemd-cryptsetup: Booting with encrypted root partition fails instantly</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/6478">#6478: `systemctl` should not consider active->failed as a successful operation</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/6620">#6620: services writing to stdout become silent after journal restart</a></li>
		<li><a href="https://github.com/systemd/systemd/pull/7184">#7184: resolved: fix loop on packets with pseudo dns types</a> (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15908">CVE-2017-15908</a>)</li>
		<li><a href="https://github.com/systemd/systemd/issues/8579">#8579: systemd breaks my mouse</a></li>
		<li><a href="https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795921">Out-of-Bounds write in systemd-networkd dhcpv6 option handling</a> (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15688">CVE-2018-15688</a>)</li>
		<li><a href="https://github.com/systemd/systemd/issues/6078#issuecomment-308240231">#6078: Applying systemd-networkd configuration disconnects all other interfaces</a></li>
		<li><a href="https://www.openwall.com/lists/oss-security/2019/01/09/3">System Down: A systemd-journald exploit (CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866)</a></li>
		<li><a href="https://github.com/systemd/systemd/issues/11810#issuecomment-489727505">#11810: Can't suspend again after suspending one time</a> (<a href="https://twitter.com/FiloSottile/status/1125840275346198529">explanation why this is bad</a>)</li>
		<li><a href="https://bugs.freedesktop.org/show_bug.cgi?id=72759">Systemd user manager interferes with ecryptfs - private directory not being unmounted</a> (also <a href="https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/313812">umount of ecryptfs does not automatically clear the keyring</a> and <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854">ecryptfs-utils: Private directory not automatically unmounted anymore on logout</a>)</li>
	</ul>
	<p>Other issues arising around systemd:</p>
	<ul>
		<li><a href="https://github.com/systemd/systemd/pull/15206">systemd will be able to kill a process if he needs/wants more RAM</a></li>
		<li><a href="https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html">We need to enforce the use of systemd to everyone, by the creator of systemd itself.</a></li>
		<li><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394">systemd kill background processes after user logs out</a> (see also: <a href="https://github.com/tmux/tmux/issues/428">[RFE] add a way to run in a new systemd scope automatically</a>)</li>
		<li><a href="https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/">Don't panic, but Linux's Systemd can be pwned via an evil DNS query</a></li>
		<li><a href="https://isc.sans.edu/forums/diary/Systemd+Could+Fallback+to+Google+DNS/22516/">Systemd Could Fallback to Google DNS?</a></li>
		<li><a href="https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1713457">DNS search domain not removed from resolv.conf on disconnect</a></li>
		<li><a href="https://fredrikaverpil.github.io/2016/04/27/systemd-and-resource-limits/">systemd does not respect system wide resource limits</a></li>
	</ul>
	<h2>How do I get rid of systemd?</h2>
	<p>Free your system by replacing systemd with an alternative init system. Here are a few guides on how to do that:</p>
	<ul

https://without-systemd.org/wiki/index_php/Arguments_against_systemd/:

TOC

* [http://fromthecodefront.blogspot.in/2017/10/systemd-no.html systemd: Please, No, Not Like This] (October 2017) * [http://ewontfix.com/14/ EWONTFIX - Broken by design: systemd] * [http://ewontfix.com/15/ EWONTFIX - Systemd has 6 service startup notification types, and they're all wrong] * [https://pwnies.com/winners/#lamestvendor Lamest Vendor Response 2017 #PwnieAwards goes to Lennart Poettering for SystemD f*ckups] [https://twitter.com/dalmoz_/status/890397041674911745/photo/1 photo] * [http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt Patrick's playground - Systemd propaganda: It's a crap!] * [http://draketo.de/light/english/top-5-systemd-troubles Top 5 systemd troubles - a strategic view for distros] * [http://wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd Systemd? More like Shit-stemd] * [http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdCrashAndMore The bad side of systemd: two recent systemd failures] * [http://landley.net/notes-2014.html#23-04-2014 ”…There are several problems with systemd unrelated to code quality…“] * [http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html Systemd: The Biggest Fallacies] * [https://forums.bunsenlabs.org/viewtopic.php?id=4346 Fast boot?] in-the-wild discussion (workarounding slow OOTB systemd boot) “Performance tuning the boot process” * [http://news.dieweltistgarnichtso.net/posts/systemd-assumptions-bullying-consent.html systemd: Assumptions, Bullying, Consent] * [https://lkml.org/lkml/2014/8/12/459 Open letter to the Linux World] * [http://fromthecodefront.blogspot.in/2017/07/systemd-pitfalls.html systemd pitfalls] (July 2017) * [http://mrpogson.com/2015/02/09/systemd-or-poettering-name-your-poison/ systemd Or Poettering, Name Your Poison] * [http://forums.debian.net/viewtopic.php?f=20&t=120652&p=570371 Combatting revisionist history] * Local copy of boycottsystemd.org archive * [https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/ Ts’o and Linus And The Impotent Rage Against systemd] * [https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU A realization that I recently came to while discussing the whole systemd controversy…] * [http://neofutur.net/systemd-vault systemd vault - Everything you need to fully understand the systemd problem] * [http://louwrentius.com/systemd-forward-secure-sealing-of-system-logs-makes-little-sense.html Systemd Forward Secure Sealing of System Logs Makes Little Sense] * [http://blog.gerhards.net/2011/11/journald-and-rsyslog.html journald and rsyslog] * [http://blog.gerhards.net/2011/11/what-i-dont-like-about-journald.html What I don't like about journald / Linux Journal] * [http://blog.gerhards.net/2012/01/disappointing-press-reactions.html Disappointing press reactions…] * [http://www.steven-mcdonald.id.au/articles/systemd.shtml Why I dislike systemd] * [https://muchweb.me/systemd-nsa-attempt/ Is `systemd` an NSA attempt?] * [http://suckless.org/sucks/systemd Systemd is the best example of Suck] (suckless.org) “There is a menace which is spreading like a disease throughout the Linux world, it is called systemd.” * [http://blog.darknedgy.net/technology/2015/10/11/0/ Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise] * [http://pappp.net/?p=969 PAPPP's ramblings - Linux Future (how systemd is not like Unix)] * [https://github.com/coreos/rkt/issues/576 Systemd requiring CAP_SYS_ADMIN weakening container safety in coreOS/rkt] * [https://bsdmag.org/randy_w_3/ Problems with Systemd and Why I like BSD Init by Randy Westlund] * [https://www.ubuntubsd.org/wiki:why_not_systemd ubuntubsd.org article titled “Why Systemd is so bad?”] * [https://www.jordynsblog.org/index.php/2017/04/30/the-reasons-why-i-hate-systemd/ The reasons why I hate systemd] * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#20 Debian Bug #668001 “debootstrap: cant install systemd instead of sysvinit”] (2014 mailing list thread, 100+ msgs)<br> the_new_order.jpg

Breaking promises and immaturity

[http://article.gmane.org/gmane.linux.hotplug.devel/17392 “After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time”] [http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html ”…this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. 'Gentoo folks, this is your wakeup call.'“] Linux (kernel) coup attempt: [http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html “kdbus support is no longer compile-time optional … We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled.”] [http://lkml.iu.edu/hypermail/linux/kernel/1506.2/03764.html comment on this on LKML ] [https://lwn.net/Articles/641275/ “The kdbuswreck”] [https://github.com/systemd/kdbus “kdbus now out-of-tree”] [https://en.wikipedia.org/wiki/D-Bus#kdbus “kdbus dropped in favor of BUS1”]

Stability Promises

To quote from the systemd [http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ stability promise]: : “Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future.” One of their [http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ promises] is for the [http://www.freedesktop.org/wiki/Software/systemd/export/ export format]: : “Entry metadata that is not actually a field is serialized like it was a field, but beginning with two underscores. ” This is not true for version 44 of systemd for example.

Scope creep
Absurd Bugs and Responses

* [https://bugs.freedesktop.org/show_bug.cgi?id=74589 Unchecked null pointer dereferencing in PID 1 not considered a serious issue] - <i>“To make this work we'd need a patch, as nobody of us tests this.”</i>, <i>“I will not work on this”</i> - Systemd <b>requires</b> cgroups and segfaults if there is no cgroups support. * [http://www.phoronix.com/scan.php?page=news_item&px=MTYwMzg Screen locking issues (including a security issue) with gnome-shell] - remained unfixed for over a year] * [http://soylentnews.org/article.pl?sid=14/12/21/1343258 PID 1 segfaulting on upgrade; journalctl usability issue] - bug report still marked as “NEW” * [https://lists.debian.org/debian-user/2015/02/msg00010.html “Tried to boot my laptop from a cafe…”] * [https://bugzilla.opensuse.org/show_bug.cgi?id=918226 systemd segfaults after updating from 208-23.3 to 208-28.1] * [https://github.com/systemd/systemd/issues/2402 Mount efivarfs read-only] - Doing rm -rf / bricks your computer * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171 Unable to shutdown] * [https://bugs.freedesktop.org/show_bug.cgi?id=61191 journald eats up CPU] * [https://bugs.freedesktop.org/show_bug.cgi?id=64116 Corrupted binary logs] * [https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet How to Crash Systemd in One Tweet] (works as any user, not just root) and [https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d response] and [https://www.agwa.name/blog/post/systemd_is_not_magic_security_dust rebuttal] * [http://www.openwall.com/lists/oss-security/2017/01/24/4 Systemd v228 local root exploit] * [https://github.com/systemd/systemd/issues/5644 tmpfiles: R! /dir/.* destroys root] See also [https://www.preining.info/blog/2017/04/systemd-again/ Systemd again (or how to obliterate your system)], Poettering's response: <i>“I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but “rm -rf /foo/.*” will work the exact same way, no?”</i> (Hint: no.) * [https://github.com/systemd/systemd/issues/6237 systemd can't handle the process previlege that belongs to user name startswith number, such as 0day] Poettering: “not a bug, a feature” * [https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime systemd Using 4GB RAM After 18 Days of Uptime]

Conceptional problems

* [http://soylentnews.org/article.pl?sid=14/12/21/0145243 Systemd Prevents the Skipping of fsck while Booting] - still unresolved * [http://soylentnews.org/article.pl?sid=14/12/21/1554227 Systemd Disables the Linux Magic SysRq Key] - closed as “NOTABUG” * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658 Please do not default to using Google nameservers] - Debian package maintainer refuses to acknowledge the privacy leak and closed the bug. * [https://github.com/systemd/systemd/issues/437 timeX.google.com provide non standard time] - Horrible default behaviour but Lennart tries to shift the blame on distros because “systemd is not a product”. * [https://bugs.freedesktop.org/show_bug.cgi?id=76935 Do not parse “debug” command line parameter] - [https://lkml.org/lkml/2014/4/2/415 Response on LKML] Response: [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c2 That is the expected current behaviour, “debug” can cause “too many” messages to be useful anymore if things are broken.] * [https://github.com/systemd/systemd/issues/2447 journal ip anonymization] - It's very difficult to use systemd/journal on a privacy aware system or infrastructure. * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 systemd kill background processes after user logs out] - Poettering's answer: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XW7V5A3RAWYCACU2ZMPA27ARRLIZUI37/ In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.] * [http://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is-broken.html systemd-resolved is broken] - doing DNS resolve wrong, with the [https://github.com/systemd/systemd/issues/5755 usual attitude towards feedback] Debunking the myth of unit files being significantly shorter than scripts used by all other init systems: [https://jdebp.eu/FGA/run-scripts-and-service-units-side-by-side.html A side-by-side look at run scripts and service units]

Scope Creep Leads to Vulnerabilities

* [http://seclists.org/oss-sec/2014/q4/592 systemd-resolved DNS cache poisoning] * To run systemd properly in container a FUSE [https://linuxcontainers.org/lxcfs/introduction/ LXCFS] had to be created, and surely its own share of vulnerabilities: [https://www.cvedetails.com/cve/CVE-2015-1342/ LXCFS before 0.12 does not properly enforce directory escapes] CVSS 4.6 [https://www.cvedetails.com/cve/CVE-2015-1344/ The do_write_pids function in lxcfs.c in LXCFS before 0.12 does not properly check permissions] CVSS 7.2 * [https://latesthackingnews.com/2017/06/29/a-systemd-vulnerability-allows-attackers-hack-linux-machines-via-malicious-dns-response/ A Systemd Vulnerability Allows Attackers Hack Linux Machines via Malicious DNS response]

Poor design

* [https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10 Improper argument parsing] * [http://www.freedesktop.org/software/systemd/man/systemd.special.html systemd has a filename that starts with a hyphen!] - This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don't even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, ”-.slice“, they refer to as the “root slice” which causes confusion as the term “slice” has been used for decades as an alternative way of referring to a [https://en.wikipedia.org/wiki/Slice_(disk) disk partition] yet their usage is completely unrelated. * [https://news.ycombinator.com/item?id=10999335 Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'] See also [https://bbs.archlinux.org/viewtopic.php?id=207549 No POST after rm -rf /] - Lennart's argument for mounting /sys/firmware/efi/efivars as read/write as a default behaviour doesn't hold water. Yes it's true that some tools may need to write to it but those tools are not needed for the general running of a system. efivars should not even be mounted as read-only by default. Those tools that need to write to efivars will generally only be invoked by a system administrator. A competent sysadmin will know how to mount efivars with read/write permissions when they need to to use those tools. The only reason to mount efivars by default is for convenience. This is by no means a good reason. From a security perspective, mounting efivars by default should be strongly discouraged as it breaks the [https://en.wikipedia.org/wiki/Principle_of_least_privilege principle of least privilege]. Lennart goes on to state that [https://github.com/systemd/systemd/issues/2402#issuecomment-177907110 systemd needs to write EFI variables]. This demonstrates yet another example of scope creep and thus poor design. * http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=28640752854 * https://bugzilla.redhat.com/show_bug.cgi?id=1170765 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 “Now you can no longer expect a long running background processes to continue after logging out. For example, you can no longer start a screen or tmux session, log out, and expect to come back to it.” * https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ systemd's predictable NIC names are actually unpredictable…

Ignorance of fundamental operating system concepts

* [http://lists.freedesktop.org/archives/systemd-devel/2015-February/028514.html Lead systemd developer doesn't understand RAID or checksum] * [https://github.com/systemd/systemd/issues/825#issuecomment-127917622 Lead systemd developer doesn't understand su, expects it to do something else and then labels it a “broken concept”] - su isn't supposed to inherit cgroups or audit, those concepts are relatively new and arrived well after the creation of su. TTYs were originally physical devices so of course su is supposed “inherit” the same device otherwise it would be truly broken. Pseudo TTYs emulate real TTYs so their behaviour is obviously expected to be identical. su really is just a simple mechanism that calls setuid(2) in order to switch to another user. If he needs to write a new utility to handle scenarios that su was never designed to handle, no problem, but to label it as a “broken concept” demonstrates a lack of understanding of what su actually is.

maybe use already installed sync plugin to pull resources from devuan wiki

As systemd doesn't follow our Social Contract, we have decided to remove it and use OpenRC as our default init system. The decision means that the Stable v0.1 will be the first and the last version supporting systemd.

To ease the transition, systemd support will remain in the stable repositories for the time being, while we are removing it in the Testing version and creating our OpenRC migration guide. As of Stable v0.2 release, systemd support will be completely removed without further notice.

Further details:

  Unchecked null pointer dereferencing in PID 1 not considered a serious issue (https://bugs.freedesktop.org/show_bug.cgi?id=74589)
  Mount efivarfs read-only (https://github.com/systemd/systemd/issues/2402)
  Unable to shutdown (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776171)
  journald eats up CPU (https://bugs.freedesktop.org/show_bug.cgi?id=61191)
  Corrupted binary logs (https://bugs.freedesktop.org/show_bug.cgi?id=64116)
  tmpfiles: R! /dir/.* destroys root (https://github.com/systemd/systemd/issues/5644)
  systemd again (or how to obliterate your system) (https://www.preining.info/blog/2017/04/systemd-again/)
  systemd can't handle the process previlege that belongs to user name startswith number, such as 0day (https://github.com/systemd/systemd/issues/6237)
  systemd Using 4GB RAM After 18 Days of Uptime (https://serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime)
  Please do not default to using Google nameservers (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658)
  journal ip anonymization (https://github.com/systemd/systemd/issues/2447)
  systemd kill background processes after user logs out (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394)
  systemd-resolved DNS cache poisoning (https://seclists.org/oss-sec/2014/q4/592)