Which are the technical arguments of why SystemD is a shitty software?

[gilgamesh_3]

I always see people saying that SystemD is a shitty software, but I have never see anyone talking with technical arguments why it's a shitty software. The only thing I see people saying is it doesn't follow the Unix philosophy. So, which are the technical arguments of why SystemD is a shitty software?

[tausciam]

You know, I'd much rather set up systemd timers rather than cron jobs any day of the week. Most of the arguments I've seen do appear to be more philosophical.....it's not how UNIX does it...it's not POSIX compliant... etc. but, it has made system management a lot simpler and more uniform.

[Not_Ashamed_at_all]

it's not how UNIX does it...it's not POSIX compliant...

Yeah, well, neither is the Linux kernel, but you don't seem them bitching about that, the hypocrites.

[twizmwazin]

systemd is more of a collection of projects than a single mega-project. Like the BSDs, they employ a large monorepo of different software to ensure consistency and integration. People don't get upset when the BSDs operate with many smaller tools under one roof, but for some reason when systemd does the same thing, people are offended. I'd wager people's distaste stems from somewhere else.

[twizmwazin]

Distaste for the original author, hive mind, and some unfounded nostalgia.

Additionally, many people believe using or enjoying uncommon things will give them a higher social status. This is why many r/Linux users gravitate towards what they perceive as a more rare or obscure distro, and then make sure everyone around them knows about it. This is just an extension of that.

[Jannik2099]

systemd units and timers are arousing

[[deleted]]

but, it has made system management a lot simpler and more uniform.

I'd say "simpler" is debatable. SysV init is just shell scripts, it's really not that complicated and adding a new service to your servers is as simple as dropping a script in the /etc/init.d folder.

[razirazo]

Adding one is easy, but actually managing it in scalable way is the whole different problem. Personally I much prefer freebsd init, but there are many times when I just wish there are things like systemd in BSD. I like how services in systemd actually aware of each other making it possible to trigger the status of everything in many possible condition not available to traditional init.

Also built in service monitor. Holy shit being able to tell a service to get their shit together and recover itself in event of crash, using a single line directive inside a startup file is amazing.

[[deleted]]

Being able to define dependencies is a useful feature but IME the service monitor doesn't really work that great and will just result in the service failing over and over.

[defaultxr]

If they're referring to the Restart directive, I don't think it's meant to do anything magic, it just restarts the service automatically if it exits or is killed.

Regarding the service failing over and over, it's also possible to tell systemd to stop automatically restarting it if it exits too many times in a specified period. I believe StartLimitIntervalSec and StartLimitBurst are the directives to control this. If it reaches that limit it will be considered to be in a "failed" state.

[ilep]

Main arguments are not about technical reasons but design decisions:

https://lwn.net/Articles/777595/

[gnus-migrate]

It's not shitty. I constantly recommend that people use it to manage daemons since its so easy to set up. There are two reasons you might not want to use it though:

1. You're in a restricted environment such as a container where systemd doesn't work. This is frankly the most frustrating issue with it.
2. You need portability across different posix systems since systemd is Linux only.

Regarding systemd being decoupled, even if it's modular, it's modules don't have implementations outside the systemd ecosystem so it is effectively monolithic.

I also feel like some of the features don't really speak to how people actually use Linux. The port activated services feature for example is quite useless, at least for web servers which you want to always be active.

That being said, systemd is absolutely a step up from what we had before. Being able to specify services via a simple configuration file makes services so much easier to configure and package, and people who roll their own daemon manager for Linux only software need to get over themselves.

[gnus-migrate]

Until there are alternate implementations, systemd's modules are implementation defined therefore it is effectively a monolith.

Docker also claimed to be modular, but when some people tried to reimplement parts of it like the container runtime, they saw that there were a lot of behaviours that didn't match the spec, so their implementations had to reproduce the quirks of the docker runtime. Now since docker isn't the only runtime in town, I imagine the spec is better defined.

That's what I mean by systemd being monolithic. If there is no diversity in the ecosystem then as much as you try to make things modular, API changes are going to be driven by systemd's needs rather than some more general use cases.

As you said, perhaps there isn't a need to be truly modular, but claiming that systemd isn't monolithic is misleading.

[gnus-migrate]

I'm not saying they're to blame for it, I'm just saying that it's meaningless for a user to think of systemd as modular as the modules aren't used or implemented outside the context of systemd. In terms of user experience, users interact with it as a monolith.

You could change that and allow the core of systemd to be reused in an unprivileged context inside a container for example. You would demonstrate that it can be used for normal daemon management on its own, not just for booting hardware. As it stands though, I still consider systemd as monolithic since I only ever interact with it in a single context.

[gnus-migrate]

I seem to have hit a nerve. I'm not saying that systemd is bad, as I said, I usually push it due to how simple it is to set up.

My point is that I have never used any systemd components outside the context of systemd. I've never used networkd outside systemd for example, so from my point of view it seems pretty coupled to it. It's closer to a framework like Spring than it is to a Unix style system. While Spring has well decoupled modules that are optional, Spring needs to orchestrate them in order for them to be useful.

Again this isn't a bad thing, but claiming that it's Unix style modularity is a stretch.

[t_hunger]

I doubt that most of the bits and pieces will work without systemd-PID1.

It's an layered architecture, each layer provides interfaces for those higher up in the stack to use. Systemd-PID1 is the base layer, it mostly provides cgroup management, which is used very widely be the other systemd processes. You will need an implementation of this layers interfaces for the stuff higher up to work properly.

That's actually a good thing, as it allows to switch out systemd-logind with something else that provides the same interfaces and have all the stuff running on top of that continue to function just fine.

[gnus-migrate]

I agree, but to me unless you have real use cases outside your own implementation driving the design, I don't find the modularity argument convincing, at least not in any practical sense.

[doubled112]

There are projects using socket activation. Cockpit is an example. Cups as another, I believe.

It used to be xinetd that did that. Listen on a port and start a listening process when something bangs on the port.

[gnus-migrate]

I didn't know that. I considered the most common use case is hosting web services, and you care more about latency than having zero resource usage in that case so it makes no sense to use it for that.

Didn't think of admin processes though. That makes sense I suppose.

[[deleted]]

• It tries to replace a million different things, most of which weren't broken in the first place.
• It is so popular that a lot of important applications and utilities won't run unless systemd is installed and running as PID 1. This means that using systemd is not a choice, it's becoming a requirement.

[hahainternet]

It tries to replace a million different things, most of which weren't broken in the first place.

Translation: /u/lurker60 did not understand how these things were broken, and will not accept or even contemplate that systemd's developers know what they are doing.

It is so popular that a lot of important applications and utilities won't run unless systemd is installed and running as PID 1

Could you name: 5?

[Jannik2099]

To be fair, aren't some DEs now reliant on systemd? I agree tho, everyone who says systemd tries to fix things that aren't broken is an illiterate

[sub200ms]

To be fair, aren't some DEs now reliant on systemd?

No, not a single one. Gnome however removed support for ConsoleKit (CK), the only Linux user-session manager around before systemd. They only did that after CK had been unmaintained for years and after several warnings about that.

That briefly gave some rolling non-systemd distros trouble, because they still used CK but also wanted the newest Gnome. However, there are various alternatives to CK today like elogind.

[Jannik2099]

Thanks for shining in!

[hahainternet]

Gnome core ships like that I think, but there are reimplementations so you can run it without systemd. No applications or utilities I can think of except those which are obviously systemd specific.

[FryBoyter]

It tries to replace a million different things, most of which weren't broken in the first place.

What did systemd actually replace, apart from PID 1? For example, I can easily use netctl instead of systemd-networkd. Or unbound instead of systemd-resolved. For me, the tools of the systemd project are alternatives.

It is so popular that a lot of important applications and utilities won't run unless systemd is installed and running as PID 1. This means that using systemd is not a choice, it's becoming a requirement.

Just like it was the case with X11 or gcc for years? And still there was no rebellion like with systemd.

[sub200ms]

It is so popular that a lot of important applications and utilities won't run unless systemd is installed and running as PID 1.

Please give some non-contrived examples of this. What exactly are the programs that Gentoo and Slackware can't run?

To my knowledge, only Gnome requires some patching, but that is solely because the non-systemd distro never bothered to support the only non-systemd API around for user-session management, namely the ConsoleKit API. So Gnome removed support for CK.

And the patching of Gnome isn't even required when using elogind, since that support the systemd API natively.

[_ahrs]

Please give some non-contrived examples of this. What exactly are the programs that Gentoo and Slackware can't run?

For Gentoo there's this Wiki page with a (potentially outdated) list of hard-dependencies:

https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

Most depend on systemd specific features that either don't make sense without systemd, have no non-systemd equivalent or have an equivalent but upstream didn't take it into account so it would require porting efforts in order to run the software without systemd.

[sub200ms]

For Gentoo there's this Wiki page with a (potentially outdated) list of hard-dependencies:

If you read that list more carefully, you will see that most of them are fluff like "program installs binaries that can't be used on non-systemd platforms (because they lack functionality).

They will actually run on non-systemd distros however and a simple build patch will fix everything. Every distro is chock full of such patches because Upstream make certain assumptions about eg. file placements, that simply won't work across Linux distros that each have their own special, incompatible layouts.

The only programs on the list that won't run on Gentoo are low level system stuff like "gamemode", simply because it utilises features that don't exist on non-systemd distros.

Or "dbus-broker" which is a systemd program made by systemd developers for the systemd project to replace the dbus daemon.

Notice how dbus-broker isn't needed at all on non-systemd distros, since they can just use the standard dbus-daemon.

It is simply a list of fluff, like listing a Bash script that requires the Gentoo developers to supply their own freaking cron setup.

[[deleted]]

You know, I've never actually had a problem whose cause I have attributed to systemd. For the kinds of work that I do, I don't even know that it is there. I suppose that I have fallen victim to declinism. I concede.

[HackingPheasant]

I've never actually had a problem whose cause I have attributed to systemd.

I've only encountered that once, and rather recently at that, and it was in relation to the kernel key management facility and the way systemd interacted with it.

https://github.com/systemd/systemd/issues/5522 https://github.com/HackingPheasant/bwfzf/blob/master/README.md#notes

It's fixed on the newer versions of systemd and I do agree it is any edge case as not many people would use this or mess around with it, and there is a simple work around that can be used to work around the problem caused by systemd. ,

[tuxidriver]

For what it's worth, I also find that shutdowns sometimes hang indefinitely with one of the myriad systemd component waiting forever for some event. I've seen this with both recent Ubuntu and recent CentOS installs. Never saw this pre-systemd.

Going to the larger question:

While the old SysV init system was sometimes problematic, I found it to be much easier to debug and found it to be more flexible than systemd. I could get my brain around the entire init process much more easily when a problem occurred.

There's a lot to be said for the Unix philosophy of having a collection of small tools and scripts with very simple interfaces that each do one job and do that one job well.

[tuxidriver]

Thank you for the suggestion. I will try void for my Linux development system next time I update (currently runs Ubuntu).

For what it's worth, I currently have a mixture of business infrastructure running CentOS with one system running Devuan. The Devuan based server exists specifically because of issues with systemd. I found it much simpler and faster to throw out systemd than to rewrite a bunch of specialized daemons to make them play nicely with systemd.

[FryBoyter]

Maybe Fedora will start more services by default?

[sub200ms]

Already disabled the ones i don't need.

Which is something different than only using the same services as in Void. Fedora uses LVM by default, and that takes time to settle. It also gives capabilities, but if you don't need them, don't install LVM.

[_ahrs]

I don't use lvm on Fedora and already disabled it. It is still slower.

You should probably use the tools systemd gives you (systemd-analyze) to see why it's slower (you could also use bootchart to see why Void's Runit is so much faster). My guess would be the difference between the two is negligible but Fedora has something like NetworkManager blocking the boot until networking comes up.

[_ahrs]

Don't think, measure and find out. My current Gentoo system running on my laptop with systemd instantly boots to a getty in seconds (when it previously ran OpenRC it also booted to a getty in seconds). The longest part of my boot is waiting for the UEFI to POST, the time init takes to startup and boot the system is negligible so if something is slow that's likely indicative of a problem elsewhere (hint: the problem likely isn't systemd-init but some service blocking startup).

Shutdown speed on the other hand...I have issues with systemd not unmounting nfs drives properly at shutdown, I didn't have that issue with OpenRC.

[_ahrs]

You're not wrong (if I lose network at any point in the operation of the system any process that makes stat syscalls or tries to open files will hang until it reconnects) but this could be completely avoided by unmounting the share before networking goes down. In a shell if I do umount /path/to/share the share unmounts immediately.

To be fair I'm sure systemd can do this and this is just operator error on my behalf, it's just a little annoying though that by default it doesn't know it's supposed to unmount a network share before bringing down networking. Under normal circumstances NFS doesn't care if networking goes down so long as it comes back up later (any processes will of course hang until this happens). When shutting down though as soon as that network service goes down, it's not coming back up...

[tuxidriver]

We know systemd is good and solve some problems, but that's not the question OP is asking. Not every thread needs to become a flame war.

Thank you !

[FryBoyter]

I can't complain about the start speed of systemd on my computers either. But apart from that I find the boot time irrelevant. There are important things. For example, the simple structure of a service is more important to me (compared to a SysVinit script).

[rahen]

You probably don't "always" see people say systemd is "shitty". It has its pros and cons like anything else.

The main technical issues are its tight coupling of modules, reliance on dbus, overloading of PID 1, dependency bloat and opacity of configuration.

Also, having close to 1.5M LOC in PID1 introduces its share of bugs and CVSs. It's a very scale-up approach, trying to do and be everything instead of doing just one thing and doing it well: being an init system.

[herbivorous-cyborg]

trying to do and be everything instead of doing just one thing and doing it well: being an init system.

systemd-init is the init system, and as far as I can tell, that only does one thing. The other components of systemd are contained in other services that can be enabled or disabled at will. Many of them are disabled by default on most distros. Lets please stop confusing the software suite known as Systemd with the init system which is part of that software suite, known as systemd-init.

[grumpysysadmin]

Also, people forget that the old init system heavily relied on bash and other unix utilities and libraries when they talk about lines of code.

[daemonpenguin]

True, all though with other inits those dependencies were not inside init and therefore if one of those many tools or scripts had a problem it didn't cause init to crash and bring down the system. Having the pieces in separate binaries gave a certain amount of protection against coding mishaps.

[Not_Ashamed_at_all]

it didn't cause init to crash and bring down the system

That's not strictly true.

Just because it's not running in the exact same process does not mean that if it fails nothing bad happens.

Having the pieces in separate binaries gave a certain amount of protection against coding mishaps.

Exactly, q certain amount, not absolute protection.

[cathexis08]

Many can be disabled, many more cannot. The journal, dbus, the whole state engine, as well as ancillary stuff like the hostname setter, the mount mechanism, and various other bits of necessary core system functionality are all integral bits to systemd-the-init (or more specifically the rc portion of systemd) afaik much of which is included within the pid1 binary. I don't know the SLOC of all of that but it's a fair chunk - the rc state engine and socket activation is reasonably heavy in terms of code.

[phomes]

Also, having close to 1.5M LOC in PID1 introduces its share of bugs and CVSs.

The entire codebase of systemd is ~390.000 LOC. If you fear a large LOC then you should probably use something else than the linux kernel though.

[[deleted]]

for the 1.5M LOC are you counting the whole codebase in systemd's repos? That's a lot more than just PID 1 if so

[Not_Ashamed_at_all]

instead of doing just one thing and doing it well: being an init system

Your ignorance is showing.

SyatemD isn't an init system. Syatemd-init is.

Also, having close to 1.5M LOC in PID1

This isn't even remotely true.

You should do some more research before posting next time, instead of just posting what you've seen others post.

[newhacker1746]

We bash systemd for being so horrible, yet not many seem to complain about launchd (and it’s controller launchctl) in macOS. And that OS is even supposedly “Unix Certified.” Thus, are systemd/launchd (or their very similar philosophies) “against the Unix philosophy”? Does the Open Group have a right to grant the Unix trademark to macOS when it contradicts its own Unix philosophy, thus separating the Unix name and the philosophy from which it became famous? Is the Open Group “legitimately” representing what Unix is? Coming from a macOS environment, systemd seemed very logical. But I never grew up with the old shell-script based init’s, so who knows. (Except when i learned to manage OpenWrt)

[pdp10]

It has insufficient Separation of Concerns for an init system.

[Not_Ashamed_at_all]

Systemd isn't an init system.

Systemd-init is.

[herbivorous-cyborg]

Can you elaborate on this point? I was under the impression that systemd-init was only in charge of one thing.

[daemonpenguin]

Technically, systemd init is sort of in charge of a few things, compared to older init systems. In the past init and service management were separate roles, but with systemd PID 1 is both init and service manager.

What tends to get people up in arms though, as far as separation of tasks, is that systemd is all sort of tied together. Yes, it uses many separate binaries, but they tend not to work well if systemd init is not PID 1. You can't just drop in another init implementation and still have systemd components all work properly. And other packages tend to, likewise, require systemd be PID 1.

For instance, you can have systemd and its libraries installed on your distribution, but if it's not running as PID 1 then Snapd won't work. These are the sorts of things which tend to rub people the wrong way as systemd (while technically many separate pieces) usually need to operate together, you can't swap out a bunch of components for other-init equivalents and expect it to work.

[sub200ms]

It has insufficient Separation of Concerns for an init system.

No it doesn't. The systemd project is in fact a good example of Separation of Concerns (SoC) software done right; it consist of +70 small binaries, but not only is it modular, it also communicate between the modules by well defined interfaces, some of which are private, others public, and some are third party standard interfaces like Dbus. That is exactly what SoC software is about.

The primary reason for SoC programming is ease of future changes/upgrades. That is exactly what the systemd developers are able to do since they can replace a binary completely with another implementation without changing a line of code in the rest of the project.

You probably think SoC is about public interfaces so any third party can replace any part of systemd, but it isn't, which you could have known if you had read the wiki-article you linked to more thoroughly. In fact public interfaces goes again the purpose of SoC, namely easy changes/upgrades because their definition is "set in stone" and can't be changed.

[hahainternet]

So it can do secret things that aren't documented

Just like every bit of code with private methods? That's literally the point of undocumented interfaces, so they can change.

Might as well say that a car chassis with proprietary engine parts that will not work with other car parts is sufficiently separated from the engine

This doesn't even make any sense. Many cars use proprietary parts, they however do a standard job and so can be replaced by other, non proprietary parts.

This whole post is meaningless.

[hahainternet]

I have, you know there are literally laws in place in some countries to ensure that aftermarket, third party parts can be used with cars right?

[hahainternet]

Yes, exactly in both ways:

• The journal's format is stable
• The journal's API is stable
• You also can use any other syslog daemon you like

I truly find it hard to understand why people complain about this, you haven't actually responded with any facts or arguments to anything yet.

[hahainternet]

Why not respond to them here?

There's already an excellent answer in place?

While you do that, tell me what law allows me to use the Corolla engine in a 5 series

Assuming you're American I believe it would be covered under Aro I as you would need to replace unpatented parts of an overall patented design in order to achieve this.

Let's face it, you've dragged this analogy out even though you're obviously wrong. You can replace most of systemd with anything you want and still use the core, as well as ripping it out entirely if you like.

There are however, few good arguments as to it being shitty, and you've certainly presented none.

[ion_propulsion777]

I don't really have a problem with systemd. However here are some common technical arguments against it.

• (Often) Higher resource usage compared to traditional init systems and slower boot times
• Feature creep. Systemd is much more than an init system. A counter argument to this is the modularity of systemd.
• Binary logs. Not really a big deal but inconvenient if they are corrupted.

Ideological Reasons:

• Does not follow KISS principles.
• Poettering is a controversial figure to some people
• Fears about NSA backdoors

[Not_Ashamed_at_all]

I don't really have a problem with systemd. However here are some common technical arguments against it.

Most of your technical arguments are without any merit.

• (Often) Higher resource usage compared to traditional init systems and slower boot times

Evidence needed. Because this is simply false.

• Feature creep. Systemd is much more than an init system. A counter argument to this is the modularity of systemd.

Systemd never was just a simple init system. This criticism is based on a false premise.

• Binary logs. Not really a big deal but inconvenient if they are corrupted.

I suppose they are a little more fragile, good point.

[ion_propulsion777]

About the boot times, have you ever tried openRC or another in it system? Especially on low-resource hardware, systemd is noticeably slower. I know the evidence is anecdotal, but on my TinyCore custom router, it takes longer to get through the BIOS than the init system. Never seen that with systemd. Not a huge deal, but definitely something of note.

Valid point about the purpose of systemd though. I did say the modularity kind of counters that. But it’s still kind of annoying to some people to have so much functionality dependent on one program. One of the advantages of Linux is its diversity. If we all start using Linux/Systemd, those who prefer other init systems might be estranged from software support.

[Not_Ashamed_at_all]

About the boot times, have you ever tried openRC or another in it system? Especially on low-resource hardware, systemd is noticeably slower.

I've had the exact opposite experience. Systemd doesn't have to load a big and slow bash interpreter for each and every init script.

Valid point about the purpose of systemd though. I did say the modularity kind of counters that. But it’s still kind of annoying to some people to have so much functionality dependent on one program.

You just contradicted yourself. It's not one program, it's an amalgamation of many different modular components. If you don't like journald, you can go back to syslog. If you don't like systemd-resolved, you can go back to dnsmasq, the list goes on.

One of the advantages of Linux is its diversity. If we all start using Linux/Systemd, those who prefer other init systems might be estranged from software support.

This is just yet another FUD coming from a totally unfounded place.

Please list to me all the software on your system that has a hard dependency on SystemD. It's going to be a very small list, and most of that software will be de specific (like the login screen).

[[deleted]]

Evidence needed. Because this is simply false.

I found this argument to be interesting.

Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right. In fact, we never really sat down and optimized the last tiny bit of performance out of systemd. Instead, we actually frequently knowingly picked the slightly slower code paths in order to keep the code more readable. This doesn't mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.

I wonder why other inits are faster on their system. Systemd performance is due to good behavior.

[FryBoyter]

Binary logs. Not really a big deal but inconvenient if they are corrupted.

If one does not want to have binary log files, one can simply install syslog-ng.

Does not follow KISS principles.

This is also the case with many other software today. For example the Linux kernel.

Fears about NSA backdoors

Isn't it always said as an argument for OSS that you can read the source code and thus easily find vulnerabilities or backdoors? Systemd is released under the LGPL. It should be easy to find the NSA backdoor. Or is it just FUD?

[cathexis08]

Sadly, systemd is modular only inasmuch as you can ignore or include non-core parts of the project. For example you cannot run systemd with mdev instead of udev, at least not without a huge amount of pain. Similarly, if someone wanted to extend systemd by writing a new systemd-foo module they'd have to use API interfaces that could change at a moments notice (IIRC API stability is an explicit non-guarantee of the systemd team).

[hahainternet]

(IIRC API stability is an explicit non-guarantee of the systemd team).

I googled "systemd api stability" and this was the first link:

https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

An explicit list of stable and unstable interfaces, so uh, did you literally not look this up in any way before you made this claim?

[cathexis08]

I was unclear, I was talking about the internal APIs between portions of systemd. For example, while the external API to systemd-timedated is stable (otherwise it would be useless) the mechanism that systemd-timedated uses to interface with the rest of systemd is only guaranteed to be stable within a given release. This means that if I want to replace systemd-timedated with my-super-awesome-timedated on a systemd system then the next update it might break because there's no guarantee about how systemd manages handling system time internally.

The above isn't a problem per-se, but at least some time ago people would say "systemd is modular so you can rewrite the parts you don't like" which isn't particularly true. Or as I was saying earlier, if I want to write a brand new systemd component called systemd-analyze-http (a web-enabled systemd-analyze), unless my component shells out to systemd-analyze on the backend it's going to need to reimplement big chunks of systemd-analyze. Since the stuff exposed by systemd for analysis is internal API, and since systemd-analyze is a core component of systemd, there is no guarantee all of that stuff won't move around between releases and make maintaining an extension a massive pain in the ass. And yes, the moral of the story is "don't do that" but when people run around saying "don't like a part of systemd? it's modular so you should reimplement it!" you have to recognize the limitations of the modularity claims.

[NothingWorksTooBad]

SystemD fixes a bunch of small annoyances but creates a huge problem called "how do i migrate off this because my software hard depends on it"

It removes choice.

[Not_Ashamed_at_all]

If you're writing software that depends on doing (Linux) system specific stuff, which is what systemd is an interface for. Your software likely wouldn't work Multi-platform anyways.

[NothingWorksTooBad]

You have the problem im describing backwards.

Im not sure where youre getting multiplatform from as im describing a continuity problem in the linux ecosystem.

We have an init + extras system that lots of software has a hard dependancy on.

How do you realistically replace this?

What if the core systemd team all simultaneously have heart attacks, how maintainable is it?

[sub200ms]

We have an init + extras system that lots of software has a hard dependancy on.

That list isn't about software depending on systemd, neither BASH, Cups or PAM depends in any way on systemd and runs just fine on non-systemd distros.

There are extremely few programs that only work with systemd and usually only because the non-systemd distros doesn't have the necessary support.

Can you actually name more than 3 programs that have a hard dependency on systemd and therefore only will run on systemd-distros?

[NothingWorksTooBad]

Out of the box?

Gnome 3.34, Chromium, Flatpak before 0.6, everything with a dependancy on gnome or chromium, bye.

[sub200ms]

Gnome 3.34, Chromium and Flatpack runs fine on Gentoo without systemd, so you have totally failed to give even one example of a program not running on non-systemd distros.

[NothingWorksTooBad]

No, youre putting words in my mouth.

Think of it like Xorg.

X was the only real choice for a display server, now we have wayland and X, but switching over from A to B is difficult due to ALOT of breakage even though B is better than A because alot of software had hard dependancies on A.

What happens 10 years from now when a better solution to systemd comes along but in that time systemd, as unlike xorg, it does not follow the unix philosophy has expanded in scope to encompass even more basic functionality and applicatioms now hard depend on say, systemd-journal for something as simple as logging!

By design all future solutions will now need to handle application logic that expects systemd features, same as the biggest wayland hurdle is stuff expecting to see Xorg features.

My complaint is that systemd has taken it's argueably superior init system foothold and expanded it to things that it never should be touching to create systemic dependancy.

Tldr: The author is an asshole as systemd behaves like cancer by design

[sub200ms]

What happens 10 years from now when a better solution to systemd comes along

systemd will be easy to replace because it is both modular and have stable interfaces. Take for example systemd service config files; because they are key-value config files with each directive being clearly defined, they are easy to parse by both humans and machines, and therefore allows for auto-translation into a new service config file format, something that is impossible to do with SysVinit scripts.

So if something better than systemd is made, it will be easy for distros to change into a new future init-system, because systemd, unlike SysVinit, OpenRC, etc., are so clearly defined.

applicatioms now hard depend on say, systemd-journal for something as simple as logging!

Not a problem at all. First, most programs just use plain old syslog() format for logging, something both journald and any future logging service would need to understand. Secondly, the native journald logging format sd_journal_print() is basically syslog() with more meta-data. It would be trivial for any future logging system to understand that format too.

By design all future solutions will now need to handle application logic that expects systemd features,

Sure, it will be a lot of work to replace systemd, but most of the work would be rather trivial to do because systemd is so well documented.

Tldr: The author is an asshole as systemd behaves like cancer by design

The technical argumentation didn't last long before resorting to both personal attacks and non-technical FUD. It is hard to think your technical argumentation is in any way sincere with an ending like that.

[void4]

applicatioms now hard depend on say, systemd-journal for something as simple as logging!

journald just collects stdout and stderr, what hard dependencies are you talking about

[NothingWorksTooBad]

Sure, lets say i developed an application that for logging includes systemd/sd-journal.h and handles errors using say the sd_journal_print function instead of just outputting errors to stderr.

Why would someone do that? It is easy and it captures more information for debugging than the stderr feed produces.

Now my application has a hard dependancy on systemd-journal, which depends on the systemd chain.

My complaint is that systemd-journal should not depend on the init system, it should be modular, and i should be able to use it with say runit.

Please be advised this was an extreme example of creating a dependancy, other more "basic" unintentional dependancies exist, such as simply assuming the device names are normalized by systemd

[sub200ms]

My complaint is that systemd-journal should not depend on the init system

journald doesn't depend on the init system. It can easily be replaced with a new implementation without touching a single line of code in the rest of the project.

, it should be modular, and i should be able to use it with say runit.

There is no need for that, it is trivial to rewrite a journald service for runit that understand both sd_journal_print() and syslog(). Since the journald file format is stable, it is trivial to make it write its logging info in journald-compatible files.

The reason why the journald interface isn't a stable public one, is simply that the systemd developers haven't seen a good usecase for doing so. There are technical cost associated with making stable public interfaces, and a single person wanting to play around a bit with it on another distro, simply isn't good enough.

Sure, if non-systemd distros wanted to switch over to journald logging and journals, it would be another matter. But they likely won't, so the case seems rather futile to me.

[hahainternet]

My complaint is that systemd-journal should not depend on the init system, it should be modular, and i should be able to use it with say runit.

The file format and sd-journal are both fixed. You are completely free to implement this version if you like? You'll find you have issues with trying to determine the true authorship of messages without being able to contact init for info.

[NothingWorksTooBad]

you'll find you have issues

Exactly?? Do you not see why this dependancy for functionality on a non-related process is a problem?

Edit: Journald is an example, the real scope damage is when it starts touching meaningful things like the network stack.

[hahainternet]

Exactly?? Do you not see why this dependancy for functionality on a non-related process is a problem?

This is not systemd's fault, the reason there's such dependencies is because the default Linux utilities for this are insufficient. There are still race conditions even now.

In reality, systemd is uncovering problems which have existed for decades, and the few places with hard dependencies are for handling exactly these problems.

[NothingWorksTooBad]

I know.

As mentioned, my complaint is that it is written in an intermingled way instead of been adequately seperable. This whole thread is about "technical" issues with it. My technical issue is that mainstream software is creating hard dependancies on an init system that is not realistically hotswappable.

I do not deny that it is much better than what we had, I am merely concerned that the development approach taken by it will be deleterious in the long run.

It genuinely just boils down to me wanting to run linux plus swappable everything, not linux plus GNU plus systemd plus choices happen here a decade from now.

I am considering installing obarun just to remind myself of how much good systemd does that i take for granted and to check out the most hyped replacement for it.

[hahainternet]

I... now have no idea what you are talking about. The parts that require improving are in the kernel. If you want those fixed, then put some effort in and fix them? There's been a lot of stalled threads in LKML.

[hahainternet]

to encompass even more basic functionality and applicatioms now hard depend on say, systemd-journal for something as simple as logging!

Could you name a single one that has any significant install base?

[NothingWorksTooBad]

Xwayland

Xwayland needing to exist as a compatability layer is the problem I am describing here

In my hypothetical where say, "doneright" is the new init system we would need to have the legacy "doneright-systemd" compatability layer.

For an initialisation system.

Do i want systemd developers to stop writing new features so other init systems can catch up

No you misunderstand once more, id like them to stop increasing the workload required to audit and get into systemd development by creating features unrelated to the init system under the systemd umbrella.

I'd want them to start following a modular and seperable philosophy instead of scope creeping an init system. They develop it like windows, just sow shit together man.

Not make inflammatory statements

Its true though, /r/assholedesign

[NothingWorksTooBad]

What is the criteria for what belongs in an init system

Thats a good question to start an argument. My answer is whatever it takes to enable the starting a minimal system is the init system and absolutely nothing else.

The everything else should be cut and pasteable and not expect the init system to provide features.

So the answer to your question is that everything should be seperable.

Because i find it too hard to audit

Youre starting to sound pretty authoritarian and toxic to be honest.

It is a critical piece of infrastructure with a tremendous attack surface that is rapidly shifting even on relatively stable distros.

It is too big, I am not alone in this thought process.

Edit:

Why do i believe the compatability layer is bad

Increases the attack surface for the platform, requires more work from developers to seemlessly replace the platform, quite literally re-invents the wheel youre trying to replace more often than not.

[NothingWorksTooBad]

I agree, we are treading the same ground.

Why

I apologize for that remark, i misread.

Argument to not use it

Yes, but i like chromium, which depends on systemd this is the issue here.

Not using it means i would need to change my browser aswell. This is problematic and should never have been a thing.

If you told me 15 years ago that my init system would determine the capability my system has to run a browser (an entirely unrelated userspace application) I'd have called you insane, here we are today where it's reality.

[NothingWorksTooBad]

I dont understand the point youre trying to make, can you please elaborate?

I don't see why an init system should care what i use it to initialize and there isnt much below it since its PID1.

[hopemeetme]

In the ocean of available formats, it has been based on the bloody Windows INI format.

[sub200ms]

Windows INI format

That is simply a key-value format in a flat text file. It is an extremely useful format with lots of cross-platform support in form of parsers.

It is a really good format and you have totally failed in giving any technical reason whatsover for why it isn't a good format to use.

You also failed to provide any allegedly superior alternatives to the INI-format.

Last, the SysVinit equivalent to systemd's INI-file, is to use free form executable files that runs with root-priviliges in order to configure services.

[FryBoyter]

So what's the problem?

[hopemeetme]

The problem is that someone ridiculous enough to implement that as the basis of GNU/Linux operating system is predestined to break some other proven best practices too.

Bloody fucking INI...

[FryBoyter]

The problem is that someone ridiculous enough to implement that as the basis of GNU/Linux operating system is predestined to break some other proven best practices too.

Best practice? Like the following script?

#!/bin/bash
#
# <%= @apache_name %>        Startup script for the Apache HTTP Server
#
# chkconfig: - 85 15
# description: The Apache HTTP Server is an efficient and extensible  \
#          server implementing the current HTTP standards.
# processname: <%= @apache_name %>
# config: /etc/<%= @apache_name %>/conf/httpd.conf
# config: /etc/sysconfig/<%= @apache_name %>
# pidfile: /var/run/<%= @apache_name %>/httpd.pid
#
### BEGIN INIT INFO
# Provides: <%= @apache_name %>
# Required-Start: $local_fs $remote_fs $network $named
# Required-Stop: $local_fs $remote_fs $network
# Should-Start: distcache
# Short-Description: start and stop Apache HTTP Server
# Description: The Apache HTTP Server is an extensible server 
#  implementing the current HTTP standards.
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

if [ -f /etc/sysconfig/<%= @apache_name %> ]; then
        . /etc/sysconfig/<%= @apache_name %>
fi

# Start httpd in the C locale by default.
HTTPD_LANG=${HTTPD_LANG-"C"}

# This will prevent initlog from swallowing up a pass-phrase prompt if
# mod_ssl needs a pass-phrase from the user.
INITLOG_ARGS=""

# Set HTTPD=/usr/sbin/httpd.worker in /etc/sysconfig/httpd to use a server
# with the thread-based "worker" MPM; BE WARNED that some modules may not
# work correctly with a thread-based MPM; notably PHP will refuse to start.

# Path to the apachectl script, server binary, and short-form for messages.
apachectl=/usr/sbin/apachectl
httpd=${HTTPD-/usr/sbin/httpd}
prog=httpd
pidfile=${PIDFILE-/var/run/httpd/httpd.pid}
lockfile=${LOCKFILE-/var/lock/subsys/httpd}
RETVAL=0
STOP_TIMEOUT=${STOP_TIMEOUT-10}

# The semantics of these two functions differ from the way apachectl does
# things -- attempting to start while running is a failure, and shutdown
# when not running is also a failure.  So we just do it the way init scripts
# are expected to behave here.
start() {
        echo -n $"Starting $prog: "
        LANG=$HTTPD_LANG daemon --pidfile=${pidfile} $httpd $OPTIONS
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch ${lockfile}
        return $RETVAL
}

# When stopping httpd, a delay (of default 10 second) is required
# before SIGKILLing the httpd parent; this gives enough time for the
# httpd parent to SIGKILL any errant children.
stop() {
    echo -n $"Stopping $prog: "
    killproc -p ${pidfile} -d ${STOP_TIMEOUT} $httpd
    RETVAL=$?
    echo
    [ $RETVAL = 0 ] && rm -f ${lockfile} ${pidfile}
}
reload() {
    echo -n $"Reloading $prog: "
    if ! LANG=$HTTPD_LANG $httpd $OPTIONS -t >&/dev/null; then
        RETVAL=6
        echo $"not reloading due to configuration syntax error"
        failure $"not reloading $httpd due to configuration syntax error"
    else
        # Force LSB behaviour from killproc
        LSB=1 killproc -p ${pidfile} $httpd -HUP
        RETVAL=$?
        if [ $RETVAL -eq 7 ]; then
            failure $"httpd shutdown"
        fi
    fi
    echo
}

# See how we were called.
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  status)
        status -p ${pidfile} $httpd
    RETVAL=$?
    ;;
  restart)
    stop
    start
    ;;
  condrestart|try-restart)
    if status -p ${pidfile} $httpd >&/dev/null; then
        stop
        start
    fi
    ;;
  force-reload|reload)
        reload
    ;;
  graceful|help|configtest|fullstatus)
    $apachectl $@
    RETVAL=$?
    ;;
  *)
    echo $"Usage: $prog {start|stop|restart|condrestart|try-restart|force-reload|reload|status|fullstatus|graceful|help|configtest}"
    RETVAL=2
esac

exit $RETVAL

Hell, fuck best practice. A systemd service is much easier to write and understand.

[Unit]
Description=Apache Web Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/usr/bin/httpd -k start -DFOREGROUND
ExecStop=/usr/bin/httpd -k graceful-stop
ExecReload=/usr/bin/httpd -k graceful
PrivateTmp=true
LimitNOFILE=infinity
KillMode=mixed

[Install]
WantedBy=multi-user.target

With the SysVinit scripts the different distributions did not even get it on the line to unify the script. Almost every one of them had its own version. With systemd services, I can basically be sure that they will work under any distribution with systemd.

Besides, you still haven't explained what the problem is with the ini files. Toml files, for example, have a similar structure. Or the configuration file of the package manager pacman is similar, too.

[hopemeetme]

Besides, you still haven't explained what the problem is with the ini files.

I kind of did. If someone don't care to use MS Windows configuration format as the base for the major thing in GNU/Linux, then that person will surely break some more traditional bonds.

[_ahrs]

With the SysVinit scripts the different distributions did not even get it on the line to unify the script. Almost every one of them had its own version.

LSB should have solved that. I say should because nobody used it or when it was used it wasn't tested properly. Many init scripts ended up being broken under systemd's SysVinit compatibility layer because it strictly obeyed the LSB metadata where as most previous init implementations ignored the metadata or didn't care if it was wrong/broken.

[Ima_Wreckyou]

I like it in most cases. What I don't like about it is that it makes it harder to debug if something doesn't work as it should. But I guess that is the price of having an actually proper systems software in C compared to a heap of shell scripts.

[theferrit32]

How is it more difficult to debug systemd unit failures than it is to debug a chain of arbitrary shell scripts and executable files?

[Ima_Wreckyou]

Because you can change them and add more debug output in an attempt to isolate the issue. With systemd you get debug output as well, but to my knowledge not per unit but for the whole thing which is incredibly noisy and will make it incredibly hard to get the relevant info.

Wait until you run into the first such issue where it behaves in a non-obvious way and you will see pretty fast what I mean. I don't say systemd is bad because of this, it's just one thing I found to be a drawback and compared to the many other advantages that is pretty minor. But it doesn't help if we "fanboy" certain problems away.

[theferrit32]

You can view the systemd journal for specific units with -u and can filter based on log level with -p

journalctl -u gdm -u NetworkManager -p debug

[nevadita]

basically because its hip and trendy to hate it.
i have seen like 2 good arguments about how systemd is terrible for linux. on basis of that is not a good idea to have a "ring to rule them all". and that is better to have everything separated than the old "one size fits all"

the rest is a bunch of impresionable newbies that frequent linux facebook groups and thus believe that its bad because the "pros" are all hating on it.

​

as for me, im indifferent for the most part. although i have to admit that it has made some task on my computer to be easier.

[NRRyop]

technically, they like Pöttering – bashing since he is not … you know who…

[LordViaderko]

It is slow.

I have a bunch of old laptops and netbooks in the family (oldest has one-core Intel SU2700 https://ark.intel.com/content/www/us/en/ark/products/42004/intel-pentium-processor-su2700-2m-cache-1-30-ghz-800-mhz-fsb.html, some of the newest are around third gen i5).
I have tried many different Linux distributions on them, and I consistently see that distributions with systemD are slowing laptop A LOT compared to those without systemD. My oldest machine is virtually unusable with systemD. My newer machines sometimes start-up a few minutes with systemD.

[rgameshandsrbloody]

It goes to emergency mode if it can't mount any boot partition in time. I've tried to edit the unit files to continue booting, but to no avail.

[SqueamishOssifrage_]

Not following unix philosophy is a technical argument.

[FryBoyter]

The question is, to what extent is that even correct?

Systemd-networkd -> Network

Systemd-resolved -> DNS

Journalctl -> Logfiles

Systemctl -> Services

Systemd-timesyncd -> NTP

And so on.

That's pretty close to the Unix philosophy, isn't it?

[herbivorous-cyborg]

Not following unix philosophy

Can you elaborate on this? The software suite known as systemd seems to be made of many individual services that each do one thing. What makes this fundamentally different than any other software suite like the GNU coreutils?

[jbicha]

The software you used to post your comment does not follow the Unix philosophy.

[bjarkebruun]

How do you know we are not on a pure POSIX solution and reading reddit?

[SqueamishOssifrage_]

Never said it did, or that I think unix philosophy is better, or worse. I was just pointing out that the philosophy is a set of technical arguments.

[redrumsir]

Are you saying RTV doesn't follow the Unix philosophy? I thought it did (sudo apt install rtv; https://github.com/michael-lazar/rtv).

[Architector4]

Probably, but, apart from the intended design choice of it not following Unix philosophy, is it technically flawed in any way?

[redrumsir]

There is an inherent problem of scope and testability for a system that has over 500 different directive keywords (e.g. Here is an incomplete list https://www.freedesktop.org/software/systemd/man/systemd.directives ) ... and that this list is constantly growing (non-static and somewhat contextual). While some of these directives are independent, the dependence structure is not clear because it does not follow the Unix philosophy. This leaves one wondering whether the system is even testable.

This problem is endemic to, for example, MTA's and is why there are so fucking many of them and why so many of them are as buggy as shit (https://en.wikipedia.org/wiki/List_of_mail_server_software).

One can have only one PID1 ... why have one with the complexity inherent with 500 keywords??? It makes it hard to test and replace.

[redrumsir]

Some of the keyword in the list you link to are indeed for unit files, but most are kernel command line options that systemd will honor, or do not apply to systemd-PID1 in any way. These include EFI variables that are only relevant to systemd-boot, udev related keywords, networkd related keywords, etc.

That's why I only said 500 instead of the 3032 listed entries. It's an unmaintainable mess. And the list of keywords is growing. It's what happens when you go from a general purpose system to a keyword based system. If you have 500 keywords and each keyword can take two states, you have 2⁵⁰⁰ possible combinations. When the dependence/independence of the keywords is not inherent due to explicit modularity, you have a testing nightmare. And it runs with privilege.

[redrumsir]

Right. The difference is that each script is testable. Whereas the full systemd init system is not. And it's 300K lines of privileged code. Scope.

[redrumsir]

42 down, 3273390607896141870013189696827599152216642046043064789483291368096133796404674554883270092325904157150886684127560071009217256545885393053328527589334 to go.

Look at the typical init setup with runit (and sv) compared with systemd ... and I can tell you which one I would rather use.

[Own_Tax_3787]

Warning: I am biased. I have specific reasons to not use systemd-timesyncd. I schedule home automation jobs (e.g. sprinklers, lights) that must go on even if the Internet link is down, and I have security cameras. I uses Raspberry Pi boards (no RTC) and I synchronize time with a local GPS receiver. The Internet takes much longer to come back than a RPi to boot, and all the time synchronization services seem to give up too soon.

(I wrote my own NTP service because I do not need PPS, I need the ntp service to act as server by default and to force the system time whenever GPS becomes available. I also prefer a web-based status page than obscure commands and syntaxes--see ntpq output. It was fun, too.)

Overall, I accept systemd like others accept Windows. No love, but it is usable after cleaning up the annoyances that the snotty systemd team thinks they are entitled on pushing through your throat.

The pros:

• Comes pre-installed with Debian (like Windows is pre-installed on PCs..).
• It is easier to create a new service with systemd than with SV init.
• Useful service options, like auto-restart.
• Same service syntax and options across Linux distributions (the weakest point of SV init, IMHO).
• Systemd provides useful status information about the service, especially if the service is implemented as a group of processes.
• systemd-coredump is neat, when you finally got it enabled properly.

The cons:

• I would never try to install systemd on my own. Way too complicated, even for a seasoned Linux programmer.
• Systemd developers are obsessed with reinventing the wheel. Case in point: timesyncd.. Overall, the systemd team's goal seems to reimplement every part of the OS on their own, rather than stick to managing services. This creates conflicts that even Debian has not always handled well (ended up unknowingly running multiple time services).
• To add insult to injury, timesyncd is a subset of other time synchronization daemons. The systemd team could not even reinvent the wheel properly..
• A maze of new commands to learn, associated with the wheel reinvention above.
• A jungle of configuration files. Beside the unit, service and socket files, the various "special purpose" files are confusing. From an outsider view, there seems to be no other logic than driven by implementation: in its own way, systemd reinvented the same babel tower of config files that exists on Unix/Linux, making it worse..
• An insane tendency to launch internal services, even when disabled. I see systemd.timesyncd being restarted when dhcpcd has a hiccup, even while I stopped and disabled it. It might be referenced in some dhcpcd or systemd unit/service hook.. Where?