systemd

There exists a crontab → systemd timer generator.

See also:

• https://wiki.archlinux.org/index.php/Systemd/Timers
• https://www.freedesktop.org/software/systemd/man/systemd.timer.html

/etc/systemd/systemservicename@.service

[Unit]
# %I gets replaced by what you call the service with after the @
Description=rsnapshot (%I) backup

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=3
ExecStart=/usr/bin/program %I

/etc/systemd/systemservicename-daily.timer

[Unit]
Description=Put a meaningful description here

[Timer]
# 20:30 is the clock time when to start it
OnCalendar=20:30
Persistent=true
Unit=systemservicename@daily.service

[Install]
WantedBy=timers.target

• OpenRC

(source: uselessd.darknedgy.net/ProSystemdAntiSystemd)

[…]

[…]

Dumb arguments made by systemd supporters have largely been left unaddressed and left to propagate as equally as dumb arguments made by its opponents, though fewer will acknowledge the former. This was, until, on September 26 of 2014, Judec Nelson wrote a comprehensive blog post called “Systemd: The Biggest Fallacies”, which became huge on /r/linux and garnered comparatively little response on HN.

[…]

“systemd is monolithic! It implements everything inside PID1!”, says the systemd opponent, being totally wrong.

“systemd is not monolithic! Think of the 69 binaries!”, replies the systemd proponent, also being totally wrong.

Architectural arguments about systemd tend to be messes of jargon with differing interpretation, often with people assuming that something being modular automatically makes it non-monolithic. The trouble is that this is actually correct by certain definitions. On the other hand, something being both modular (at least to a degree) and monolithic simultaneously is also absolutely possible and considered the correct interpretation for various software like X.Org, Busybox and the Linux kernel.

This sort of linguistic warfare is typically a distraction from some of the more profound technical decisions made by systemd, and leads to a self-imposed lack of mutual understanding. Opponents will often refuse to drop the falsehood of a huge blob stuck inside PID1, but proponents will also refuse to admit that systemd’s modularity is not as extensive as it could be, and that its PID1 is still larger than most other systems, regardless.

Often initiated by opponents, they will lament on the horrors of PulseAudio and point out their scorn for Lennart Poettering. This later became a common canard for proponents to dismiss criticism as Lennart-bashing. Futile to even discuss, but it’s a staple.

Lennart’s character is actually, at times, relevant. Trying to have a large discussion about systemd without ever invoking him is like discussing glibc in detail without ever mentioning Ulrich Drepper. Most people take it overboard, however.

A lot of systemd opponents will express their opinions regarding a supposed takeover of the Linux ecosystem by systemd, as its auxiliaries (all requiring governance by the systemd init) expose APIs, which are then used by various software in the desktop stack, creating dependency chains between it and systemd that the opponents deemed unwarranted. They will also point out the udev debacle and occasionally quote Lennart. Opponents see this as anti-competitive behavior and liken it to “embrace, extend, extinguish”. They often exaggerate and go all out with their vitriol though, as they start to contemplate shadowy backroom conspiracies at Red Hat (admittedly it is pretty fun to pretend that anyone defending a given piece of software is actually a shill who secretly works for it, but I digress), leaving many of their concerns to be ignored and deem ridiculous altogether.

Moderation is rarely seen. Most proponents usually resort to outright denying any political meddling and insist that systemd is being adopted based solely on its technical merits, and that such a wide consensus by Linux distros cannot possibly be forged, but has to have valid technical reasons that clearly show systemd to be superior behind it.

Neither of these views are strictly true. There most likely is no Red Hat conspiracy invading all of the distribution bureaucracies (as amusing as it sounds), but to say that systemd adoption is purely technical and not at all political, is equally false. This is especially evident from the fact that just about every Linux distribution (though particularly Debian) has an elaborate governmental structure. Technical and political decisions overlap very frequently (just ask Microsoft and Oracle), and free software is not necessarily immune from it.

In addition, the Linux community is known for reinventing the square wheel over and over again. Chaos is both Linux’s greatest strength and its greatest weakness. Remember HAL? Distro adoption is not an indicator of something being good, so much as something having sufficient mindshare.

That said, the phenomenon appears not so much to be that people deny that political meddling occurs in software, but rather denying that it occurs in their camp. Opponents are also guilty of this (like in Ian Jackson’s reopening the Debian systemd resolution, which was certainly fiery in nature, regardless of its intention), though they are simply not as influential.

Expecting systemd debates not to involve politics, as such, is rather self-contradictory. systemd is already the most politically charged topic in the history of free software, and it is not so arbitrarily. Nonetheless, both sides are frustratingly obtuse and we will analyze their generic backgrounds later on, to see why.

Portability in init systems is rare, largely because stages 1 (immediately after the kernel starts init(8)) and stages 3 (shutdown) are inherently system-specific. This is also a major reason for much of the philosophical drift on init designs, even if infrequently stated so explicitly.

Proponents rightfully argue that systemd being unportable is typical and not a solid argument against it, but opponents typically point out the politics and the dependency creep, arguing that systemd doesn’t need to be init and should just be a process supervisor on top of an existing init. There are justifications to be made for both cases, though systemd’s architecture in general lends it to be an init. It trades greater security against critical errors in expense of a larger coverage, unlike the daemontools approach where you have a strict separation between system manager and service manager.

So while the portability argument would normally be a fallacy, systemd exposing APIs for other packages to use makes it relevant. Of course, the “just-world hypothesis” plays a role here, as due to this argument being intrinsically political, it is therefore often rejected outright and leads to more bang-your-head-against-the-wall (“What we’ve got here is… failure, to communicate. Some men, you just can’t reach.”) situations during debate.

Generally, a proud Gentoo user who understands the importance of unwinding all loops when compiling a package, will rise up and proclaim “Linux is about choice! systemd is encroaching on all of my software and taking away my freedom to choose!”

They will almost immediately be rebutted by someone who links them to islinuxaboutchoice.com and sometimes even goes as far as to explain why, in fact, choice is a bad thing and leads to sadness. If only we all voted for the same political party, the world would be a better place.

Excuse the caricatures, but the gist of it is that both approaches are wrong and lead to nowhere. The proponent is correct in that Linux isn’t inherently about choice, but they also often fail to realize that the Linux tradition of building systems by mixing and matching white-box components (as a result of Linux only being a kernel) has actually been quite instrumental in shaping its culture, and no doubt a reason why so many companies base their infrastructure on Linux, despite its more restrictive licensing compared to the BSDs.

In fact, none of it is about “choice”. What is actually intended is “breaking workflows”.

As it turns out, most people don’t even know what systemd is. […]

When lamenting about all the criticism (read: unabashed hatred) about systemd, the proponent will often ask “Why do so many people care about their init system? I don’t care, as long as it just works!”

The opponent will then voice their concerns by saying something to the effect of “I don’t like how systemd handles so many things like logging, containers, locale, logins, mount and automount points…”

At which point another person will yell out “But systemd isn’t just an init system, it’s a set of daemons and services for a Linux-based operating system!”

Indeed, we will see systemd variously referred to as:

• an init daemon
• an init system
• a process manager
• a system daemon
• a service manager
• a "basic userspace building block to build an OS from”
• a “dependency network between objects, usable for propagation, combined with a powerful execution engine”

etc.

Usually, when a proponent is trying to defend systemd they’ll insist it’s “just an init system”, but when challenged they will instead mention one of the broader definitions.

All of the above definitions are technically correct. None of them are complete.

It is thus that debates are doomed to go nowhere, as no one can agree on a single definition of systemd, and the developers have been largely unhelpful in that matter. Vagueness can be a strength, in that it allows for people to divide and conquer, but it is also unproductive and leads to unnecessary bloodshed. In addition, vagueness gives carte blanche for dismissing concerns and consolidating features, while also leading to a lot of ignorance from opponents and proponents alike.

systemd opponents frequently assume that the only reason people like systemd is faster boot times. This is false, though it certainly doesn’t help that fans of systemd praise that aspect a lot, even though the systemd developers themselves discourage using it as an argument, insisting it’s so because of “good design” instead (and thus the circle of flame warring continues).

The developers acknowledge that boot times aren’t as stellar by default as they could be, and most Linux distros accumulated a lot of hacks throughout the years like insserv and startpar that sped up SysV performance by augmenting its serial execution through parallelization hacks in the form of running services as background jobs.

The Unix philosophy is a gigantic flamefest of its own. It is remarkably politically charged. Many people will actually agree with a large amount of its points if you present them independently, and indeed, some of it has become synonymous with good design, but if you mention it under the umbrella of the “Unix philosophy”, bad things will ensue.

Most systemd opponents usually just blindly resort to screaming “Yoonax phoolawsaphay” like it means anything without elaborating on it, but a lot of proponents are also unusually hostile towards it and themselves misunderstand it. A common rebuttal of “Linux is not Unix” is only correct from a licensing standpoint, in that Linux is indeed, not a licensed Unix. This does not negate the fact that its architecture is intrinsically related to that of a Unix.

An email response that we received from Lennart Poettering, following an inquiry from one of our forum members, said the following:

"That all said, I am pretty sure that systemd actually brings Linux much closer to Unix than Linux ever was. All the true Unixes of today (such as FreeBSD, Solaris, …) are maintained in central place, sharing code repository infrastructure, lifecycles and release schemes, for all their compenents, regardless if its the kernel, the libc or the rest of userspace. On real Unixes it is much easier to patch through the entire stack from kernel to userspace, because everything comes from the same source, and follows the same cycles. Real UNIXes tend to feel more uniform, since the same folks work on the whole stack, things come out of a single hand. Linux always was different: our components are independently maintained, in different repos, in different coding styles, by different people, with different release cycles. They are differently well maintained, a lot of our stack is actually traditionally very badly maintained if at all.
With systemd we kinda try to find the middle position, move to a more UNIX-like scheme, without dumping everything into the same repo like UNIX does, but at least the core userspace bits. But even beyond the procedural bits, there's a lot of areas where systemd is closer to traditional UNIX than Linux was. For example, one Unix mantra is "everything is a file" (which, btw, is a pretty broken one, because my printer is not a file, not at all), and you could say that systemd exposes one of the most core concepts of a Unix system, that of services/daemons as files via the cgroup logic. So yeah, if you claim that we are not UNIX, then I'll tell you that we are actually much closer to UNIX in many ways then we ever were.
I am pretty sure that most folks who constantly repeat that systemd wasn't Unix-like like a parrot actually have no idea what UNIX really is…”

Apparently, Lennart’s takeaway from Unix is “developed in a single repository” (though this has never been a strict requirement… it’s just that individual OS kernels never really took off before the same way Linux did) and that systemd is more Unix-y than anything before it because it uses cgroupfs… even though the credit for cgroupfs’ design belongs to the kernel developers, not systemd (that and the Solaris contract file system, which was probably a major inspiration for cgroups). In addition, he enlightens us on the fact that his printer is not a file. Evidently, Lennart hasn’t heard of 9P, which is an example of a simple protocol that was successfully applied to expose nearly all system resources and services as virtual file systems, thus being controllable through the most basic of system calls that manipulate file descriptors.

After much bickering, someone will just pine in that if opponents don’t like systemd, they should write an alternative.

Of course, at least a dozen or so of them already exist. What is actually meant by “Write an alternative”?

systemd is really the userspace middleware layer that sits between GNU and Linux. I’ve also heard comparisons of systemd to servers for a microkernel, much like the Hurd. This actually makes more sense than it seems to at first glance, and with former kernel components like the Linux console being shelved out to userspace (first as kmscon, then as systemd-consoled - not implying that this is bad, by the way) does give some credence to the idea. systemd’s components often implement former standalone tools into auxiliary, programmable daemons.

As such, for one to write an alternative to systemd, a second systemd must in essence be written.

Yet this is a catch-22, as it is exactly what proponents don’t want. Many of the technically competent anti-systemd people subscribe to wholly different philosophies, such as the daemontools approach, or something else.

Further still, many ignore that writing a second systemd would be a huge risk. Doing lower level systems programming and userspace plumbing is not like doing end-user application programming. A process supervisor and a word processor are wholly different. The latter can be swapped out trivially if it is inadequate, the former requires integration and has fundamental ramifications for how one interacts with a given operating system. The task is non-trivial and has a large risk of being all for nothing. A lot of people would rather hack on personal projects than expend effort into writing systems that they largely believe have already been solved by separate and discrete tools (no doubt some of which they themselves have written).

In this regard, the “implement an alternative” argument only leads to poisoning the debate through an implicit assumption that systemd’s philosophy is inherently correct, and thus largely making things even more politicized.

It seems that through some sort of divine destiny, every systemd debate will devolve into a dead end argument about the advantages of systemd over sysvinit. The proponents will happily talk about all the nifty features of systemd that replaced all the ugly shell script boilerplate, whereas the opponents will proclaim sysvinit’s superiority in its minimalism and infinite flexibility, due to delegating services to a transparent and interpreted command language that is Turing complete.

Both are wrong and miss the point entirely.

The observation that sysvinit is dumb and heavily flawed with its clunky inittab and runlevel abstractions, is absolutely nothing new. Richard Gooch wrote a paper back in 2002 entitled “Linux Boot Scripts”, which criticized both the SysV and BSD approaches, based on his earlier work on simpleinit(8). That said, his solution is still firmly rooted in the SysV and BSD philosophies, but he makes it more elegant by supplying primitives for modularity and expressing dependencies.

Even before that, DJB wrote the famous daemontools suite which has had many successors influenced by its approach, including s6, perp, runit and daemontools-encore. The former two are completely independent implementations, but based on similar principles, though with significant improvements. An article dated to 2007 entitled “Init Scripts Considered Harmful” encourages this approach and criticizes initscripts.

Around 2002, Richard Lightman wrote depinit(8), which introduced parallel service start, a dependency system, named service groups rather than runlevels (similar to systemd targets), its own unmount logic on shutdown, arbitrary pipelines between daemons for logging purposes, and more. It failed to gain traction and is now a historical relic.

Other systems like initng and eINIT came afterward, which were based on highly modular plugin-based architectures, implementing large parts of their logic as plugins, for a wide variety of actions that software like systemd implements as an inseparable part of its core. Initmacs, anyone?

Even Fefe, anti-bloat activist extraordinaire, wrote his own system called minit early on, which could handle dependencies and autorestart. As is typical of Fefe’s software, it is painful to read and makes you want to contemplate seppuku with a pizza cutter.

And that’s just Linux. Partial list, obviously.

At the end of the day, all comparing to sysvinit does is show that you’ve been living under a rock for years. What’s more, it is no secret to a lot of people that the way distros have been writing initscripts has been totally anathema to basic software development practices, like modularizing and reusing common functions, for years. Among other concerns such as inadequate use of already leaky abstractions like start-stop-daemon(8). Though sysvinit does encourage poor work like this to an extent, it’s distro maintainers who do share a deal of the blame for the mess. See the BSDs for a sane example of writing initscripts. OpenRC was directly inspired by the BSDs’ example. Hint: it’s in the name - “RC”.

The rather huge scope and opinionated nature of systemd leads to people yearning for the days of sysvinit. A lot of this is ignorance about good design principles, but a good part may also be motivated from an inability to properly convey desires of simple and transparent systems. In this way, proponents and opponents get caught in feedback loops of incessantly going nowhere with flame wars over one initd implementation (that happened to be dominant), completely ignoring all the previous research on improving init, as it all gets left to bite the dust. Even further, most people fail to differentiate init from rc scripts, and sort of hold sysvinit to be equivalent to the shoddy initscripts that distros have written, and all the hacks they bolted on top like LSB headers and startpar(2). This is a huge misunderstanding that leads to a lot of wasted energy.

Don’t talk about sysvinit. Talk about systemd on its own merits and the advantages or disadvantages of how it solves problems, potentially contrasting them to other init systems. But don’t immediately go “SysV initscripts were way better and more configurable, I don’t see what systemd helps solve beyond faster boot times.”, or from the other side “systemd is way better than sysvinit, look at how clean unit files are compared to this horribly written initscript I cherrypicked! Why wouldn’t you switch?”

Now that we pointed out how most systemd debates play out in practice and why it’s usually a colossal waste of time to partake in them, let’s do a crude overview of the personalities that make this clusterfuck possible.

The technically competent sides tend to largely fall in these two broad categories:

a) Proponents are usually part of the modern Desktop Linux bandwagon. They run contemporary mainstream distributions with the latest software, use and contribute to large desktop environment initiatives and related standards like the *kits. They’re not necessarily purely focused on the Linux desktop. They’ll often work on features ostensibly meant for enterprise server management, cloud computing, embedded systems and other needs, but the rhetoric of needing a better desktop and following the example set by Windows and OS X is largely pervasive amongst their ranks. They will decry what they perceive as “integration failures”, “fragmentation” and are generally hostile towards research projects and anything they see as “toy projects”. They are hackers, but their mindset is largely geared towards reducing interface complexity, instead of implementation complexity, and will frequently argue against the alleged pitfalls of too much configurability, while seeing computers as appliances instead of tools.

b) Opponents are a bit more varied in their backgrounds, but they typically hail from more niche distributions like Slackware, Gentoo, CRUX and others. They are largely uninterested in many of the Desktop Linux "advancements", value configuration, minimalism and care about malleability more than user friendliness. They’re often familiar with many other Unix-like environments besides Linux, though they retain a fondness for the latter. They have their own pet projects and are likely to use, contribute to or at least follow a lot of small projects in the low-level system plumbing area. They can likely name at least a dozen alternatives to the GNU coreutils (I can name about 7, I think), generally favor traditional Unix principles and see computers as tools. These are the people more likely to be sympathetic to things like the suckless philosophy.

[…]

• Alternatives to systemd
• the biggest myths (by Lennart Poettering, main dev of systemd)

see also: http://without-systemd.org/wiki/index.php/Linux_distributions_without_systemd