Why do people hate on systemd?
Posted by RyanSetzer@reddit | linux | View on Reddit | 433 comments
Hello. I have been using systemd for years now (please do not downvote immediately) and I have seen a lot of hate for the system for a while. To me, it seems like an easy tool to use to process management and don't see the justification for the hate (that I am aware of). I have come here to "be enlightened" on why those in the community look down upon it and possibly for some alternatives. Thank you to any help you can provide.
Known-Watercress7296@reddit
It works ok.
But it's deliberately expanding in scope and has no interest in being portable or playing nice.
I can get by fine on most systems but I apprecaite those keeping portability alive and the wider unix-like community outwith glibc land.
Also Lennart was a right dick when they were forcing this stuff which didn't help matters.
Business_Reindeer910@reddit
It's not actually expanding in scope, It's finally fitting the scope it was defined for. Big difference. Read lennart's first posts 10 years on his blog. Everything we're seeing is that scope being fulfilled.
As far as portability goes, at least some musl related patches were merged into systemd for the next release. so maybe we'll see this being less of a problem going forward.
Known-Watercress7296@reddit
It is expanding in scope.
That this was the intention doesn't matter.
I don't recall a bootloader being in the early blogposts and design goals.
Business_Reindeer910@reddit
the scope is in the design, not the implementation.
blebaford@reddit
bootloader?
Business_Reindeer910@reddit
I don't see why not.
blebaford@reddit
ah so not just the design but the ideas too
Business_Reindeer910@reddit
It'll end when it runs all of the boot and controls all events on the system. Which is the whole point of systemd.
blebaford@reddit
typing a character, is that an event?
Business_Reindeer910@reddit
uhmm? it could be.. Things like the system request handler and ctrl+alt+del are "typing a character" and are handled by the kernel. So typing some other specific character or sequence could be an event.
blebaford@reddit
typing a single character or clicking a button are considered input events and are displayed by xev for example. you wrote that systemd will end when it "controls all events" which seems to reinforce the idea that nobody can say what the scope is.
Business_Reindeer910@reddit
I mean if you wanna read it like that, sure, but I don't. I don't really feel like you're engaging in this discussion with any honesty.
blebaford@reddit
that's too bad. if it's up to interpretation then there's not a "big difference" between systemd expanding in scope and fitting the scope that it was originally defined for. if you can't say whether character presses are events that are in scope to be handled by systemd, then whatever definition was given to the scope initially must be really loose.
Business_Reindeer910@reddit
you act like the scope was defined in some rigid document. it wasn't.
blebaford@reddit
you acted that way because you said the scope was "defined" in his blog posts. idk why I would read his blog; apparently it didn't prevent you from making such a silly assertion.
Business_Reindeer910@reddit
s/defined/written about/ in his blog posts if that makes things better for you.
blebaford@reddit
certainly doesn't seem like a big difference. seems like you are just taking a needlessly defensive attitude and refusing to acknowledge that the scope is expanding when it is.
Business_Reindeer910@reddit
it's a huge difference. The first assumes it started with a smaller defined scope, but kept adding stuff (which is a very common thing when building software) and the latter is actually completing what was originally wanted.
blebaford@reddit
all... events?
sparky8251@reddit
They... They didnt make it either? Its a fork of gummiboot thats still maintained.
Known-Watercress7296@reddit
Doesn't really matter if they duct tape Windows to it, it's still expanding and it's still well beyond the original scope.
sparky8251@reddit
And I'm sure youll be one of the people bemoaning an automatically configured CLAT daemon once that lands, despite Linux being the only major OS that exists without a CLAT daemon of any kind too. Windows, macOS, Android, iOS, and a bunch more of the commercial OSes all do it properly out of the box. Linux is the odd one out.
NetworkManager isnt even talking about such a thing currently, yet systemd-networkd is...
People can complain about scope all they want, but if none of the existing projects want to tackle existing problems and the advance of time itself, they are going to get left behind.
egorf@reddit
Problem with NetworkManager, netplan and others is that by the time you learn their cool new way of booting the network, they will replace it with another.
So I'm gonna use `ifupdown` for as long as it is available and probably even for some more time afterwards. Absolutely fuck their NetworkManagers, netplans, systemd-networks and other toys.
sparky8251@reddit
I mean, you say that but the only one thats been changing of those 3 for me over time is netplan, which is ubuntu specific and just configures NetworkManager or systemd-networkd under the hood.
Me knowing how to configure systemd-networkd has let me fix problems netplan has caused...
Never had a config file change in networkd or NetworkManager. Been using both for at least a decade now... So no idea how you got that idea into your head.
egorf@reddit
> Me knowing how to configure systemd-networkd has let me fix problems netplan has caused.
ifupdown → netplan → systemd-netsomething
I am staying on ifupdown since forever and thankfully it still works. It does 100% of what a server needs. Desktop is a whole different story obviously.
sparky8251@reddit
Sadly, it doesnt work for me and my servers anymore... Or well, doesnt meet all my needs anyways. The dynamism of networkd is nice for me when dealing with v6, which I've almost entirely transitioned to now.
egorf@reddit
I'm running servers with ipv6 using ifupdown but again desktop is very different and netsomething perhaps is welcome there.
Known-Watercress7296@reddit
I don't know what a clat daemon is and don't really give a shit about trying to copy Windows, MacOS, Android, iOS etc.
I'd rather linux was more in line with the bsd world than Microsoft, Google or Apple.
sparky8251@reddit
Yeah, the fact you dont know makes your assertion its about copying others patently stupid.
Its an IPv6 tech, required for 464XLAT to work. The CLAT side of 464XLAT must run on each client device, while the PLAT runs on an edge device like your router. PLAT is already handled and pretty much all the Linux networking stuff like radvd and whatever DNS or DHCP stack you want can do everything PLAT needs. CLAT however...
As for why you want any of this/what does it do? Legacy applications that use raw IPv4 connections cannot run with DNS64 setups on an IPv6 mostly network, as that means the client devices only have valid v6 addresses. DNS64 translates an A record reply into an AAAA with a specific prefix the router/edge device strips out before sending the connection off as v4.
464XLAT is used to pick up that tiny but vital fraction of applications DNS64 isnt enough for. It converts a v4 packet to a v6 packet on the client device using a prefix it gets from the networks RA and/or DNS records, the edge device then swaps back from v6 to v4 so the connection is made.
v6 mostly networks are a quickly becoming reality for many people, and pretty much all mobile networks rely on 464XLAT support from the carrier to function at all these days. Linux lacking proper easy support for CLAT setup is going to become a detriment to its adoption soon enough, especially outside of the west.
intelminer@reddit
It's not expanding in scope, it's becoming a plumbing layer in the same way that the GNU tools are tools to make using a Linux system possible
If GNU released a new application, would that be "scope creep"?
AlexiosTheSixth@reddit
are all the gnu tools dependencies of eachother?
dagbrown@reddit
Of course not. It's meant for Linux and Linux only. It takes advantage of features that only Linux provides. Heck, it exists specifically to be able to take advantage of features that only Linux provides.
What other popular Unixes are left that you think it needs to be portable with anyway? Solaris abandoned its collection of shell scripts long before systemd came into existence, as did MacOS. So are you still nostalgic for IRIX or something?
egorf@reddit
> nO InTErEst iN BEiNG PortABLE
> Of course not. It's meant for Linux and Linux only.
I think the author meant that their approach is not portable to different use cases within the realm of common sense. Of course systemd is linux-only, and that part is perfectly fine. Like you said, it specifically is.
The problem is that there is only a single right way to do things and things will be done this way whether you like it or not — that's the approach LP and his team is known to take.
For example, there is no way to properly configure systemd-resolved. Either you give up into what they think is the only right way or else. For now systemd-resolved is removable, sort of like journald has been previously.
In the next iteration you will have to figure a way to disable and surgically remove resolved, sort of like you have to do with journald today.
That's what *I* mean when I agree with the author that systemd is unportable.
GirlCallMeFreeWiFi@reddit
IDK, I love it. I understand basic usage, not difficult operations and how it works. for my understanding level it is intuitive and easy to use.
michaelpaoli@reddit
There's no shortage of stuff to [love/]like/dislike[/hate] about systemd.
As for most all of that, including the latter bits, when Debian was considering systemd, quite the discussion/debate arouse ... so much so it's considered very definitive - at least for the time - and much of it still very applicable. Pretty much every negative and positive point, pro, con, all the technical considerations, etc. So much so it's often considered pointless ;-) to further debate system, and generally just "go see the earlier discussion on the Debian list" - as any and all points of relevance that could possibly be made, discussed, argued, etc. ... been there, done that, no need to repeat it.
You can, e.g. start here: https://wiki.debian.org/Debate/initsystem
and follow relevant references, etc., to the extent desired.
And, for those who like redundancy and want to see me repeat some points made by myself and/or others, feel free to read on a bit, but the earlier probably mostly already well covers it better than I ever could.
So, you asked specifically "hate", these are some of the common "hate"/dislike points (not sayin' it doesn't have positives, but that's not what you asked):
And yes, I've had major issues with systemd ... and where that was the case I basically ripped it out and used a different init system. Also have other systems where systemd doesn't seem to be causing any particularly significant or at least egregious grief ... so those systems are running systemd. Some distros (e.g. Debian) give one a choice, whereas others (e.g. Devuan) don't ... though Devuan has done great work to make lots of software independent of systemd (I'd have rather seen such work go straight into Debian - so non-systemd init systems would be better supported more generally - notably including most all software having zero systemd dependencies).
ruyrybeyro@reddit
Devuan just made a point Debian throwing out support and most importantly, removing the choice for all non-systemd stuff, throwing out of window decades of work was more a religious crusade than a technical one
michaelpaoli@reddit
Well, with Debian, it's a choice. Though I wish Debian better supported running a non-systemd system, but still does it pretty dang well, but take a bit more care and conscious effort (and wee bit of configuration tweaking to make it particularly easy). So, I do deal with both systemd and non-systemd Debian hosts. Heck, I got so tired of folks saying, "I hate systemd, Debian uses systemd, so I hate Debian" - as if Debian didn't offer a choice ... I even did some recorded demos of how quite quickly one could switch a Debian host among different init systems.
And also for the host immediately above:
egorf@reddit
Could you please share the recipe how to switch init system on Debian? Is that just... apt install sysvinit and it... just works?
michaelpaoli@reddit
Almost that easy. Some year(s) or so back I did a demo showing how quickly the then Debian stable could be switched among - I believe it was then three - init systems which Debian offered - I seem to recall at the time there was also a fourth - but that one didn't work well at all - and that might've been just on testing or unstable.
In any case, easier to do at or closer to installation time - as there's less, to about nothing in the way that conflicts at such time. For more established systems it's bit trickier, as one will typically need to weed out installed reverse dependencies. Generally not anything major, but there are quite a few packages (e.g. notably with various mostly non-essential components of many DEs) that will rely upon systemd ... but most of the time those can be done away with.
Did also show in my earlier comment how one can configure apt to avoid accidentally (re)installing systemd-sysv which, as Debian's packaged things up, provides sysemd's init system. Not to be confused with the systemd package, which doesn't contain the init system (and one can likewise prevent that from being (re)installed if/as desired).
I forget the details, but one can also specify at installation time - if I recall correctly, suitable "kernel" options can be specified at installation boot - that will be picked up by the install system - so can make relevant selections very early on.
So, "recipe" for Debian stable from systemd-sysv to sysvinit-core (and I'll run through it again, just to confirm):
since sysvinit-core (contains sysv's init) conflicts with systemd-sysv (sets up links to use systemd as init and requires systemd which contains systemd's init), installing sysvinit-core should suffice. For the (small) Debian stable VM host under my fingertips, if I do
It shows me it will install that, and some additional packages, and the only one it will remove is systemd-sysv, so I make sure I've got it downloaded first, then install it (and I also edit /etc/inittab so in multiuser mode it'll also have login enabled on my serial console), then reboot:
And now I'm running the sysv init from sysvinit-core. If I want, I could now also get rid of the systemd package, as I no longer require it.
Informs me it can cleanly remove it - doesn't have to remove or add anything else to do so.
And if I want to get back to systemd's init, I mostly just "reverse" the process:
And I'm back to running systemd's init again. As side effect of switching back and forth, some additional packages were installed, and some configurations of removed packages have been left behind, but I can clean those up via apt-get remove and/or apt-get purge as desired. Could also prevent many of such from being installed along the way by using the --no-install-recommends, but note however Debian doesn't consider it a bug if one doesn't install the recommended package(s) and one may be missing some functionality or may have some other issue(s).
Anyway, generally not that hard to change. But for more established installed systems with thousand(s) of packages, the may be more adjustments needed. E.g. let's see ... my "daily driver" primary desktop/server (alas, both!) system under my fingertips ... if I wanted to change init system to sysv, it informs me there are 93 packages it would remove, none of which I deem that important, let alone critical, yet, egad, they've somehow all go some direct or indirect dependency upon systemd-sysv:
And, as I'd suggested earlier, if one has a system using sysv init and wants to keep in that way, I suggest those apt configuration changes I earlier suggested, to avoid unintentionally (re)installing systemd-sysv - and can likewise ban the systemd package if that's also desired.
Flash_hsalF@reddit
Very cool
egorf@reddit
Thank you so much for the detailed explanation!
ruyrybeyro@reddit
You can sort of do it indeed, however it leaves a lot of systemd cruft behind.
I used to have VMs using up 20-40MB of RAM, now you only manage VMs with 10 times that.
michaelpaoli@reddit
Well, still trims it quite a bit going from systemd to sysvinit-core:
When I change the above to sysvinit-core:
So, does free up fair bit more RAM. But I find the limiting factor is in boot - I think initrd or the like takes fair bit of RAM to boot that way. Can change that to boot other ways and trim that down further ... but so far I haven't bothered to do that - but that's where the next big savings in RAM are potentially available ... but shifting from systemd to sysvinit-core did free up about fair bit more RAM that can be used for, e.g. more applications or whatever - so yeah, systemd is still more of a RAM hog - even in a quite minimal stripped down configuration.
egorf@reddit
Agree. This is why I don't run Devuan despite being a devoted systemd hater.
I accepted systemd as PID1 and it's actually nice, but I'd love to never have to touch anything else of systemd and especially bloated features of systemd-as-init, like timers.
ghjm@reddit
There are considerable advantages to systemd and I understand why all the distros switched to it. But as an old Unix guy, it breaks a few things I cared about. Specifically:
grep whatever /etcwill find the configuration of whatever. Some configuration is now in binary format and can't be searched for textually.tail -fed. You have to use journalctl, which doesn't quite do everything the old textutils tools could do (though maybe it handles huge log traffic a bit better).None of this really matters when you're working with a carefully managed, well-understood system. But in the real world that's often not the hand you're dealt. When you have to do "forensic IT" and figure out what craziness the last guy did and how it worked, it was considerably easier when everything was textual. There were fewer opportunities for people to bury crazy config in hard-to-reach corners of the system.
eras@reddit
True. You'd need to find the base configurations from /usr/lib/systemd as well. Oftentimes
systemctl cat foo.servicewill do, but if you want to find e.g. references to a particular thing from any configuration, then that won't do. You could use something like this, though:TIL. What configuration is that?
I have
/var/log/{sys,{kern,user,auth}.}logthat are written byrsyslogdthat listensjournald, so grepping works fine. Though I actually only noticed that now, seemsjournalctlgoes quite far for extracting data from the logs. In particular getting the logs of a certain service is quite a nicer experience withjournalctlthan withgrep.I don't recognize this. What kind of examples were you thinking of?
frymaster@reddit
TIL. I make extensive use of drop-ins (they're fantastic, no need to overwrite a package-provided file and run into conflicts during updates), and I've been doing
systemctl status foo.serviceand individuallycating the files it shows me, which is probably still a useful thing when showing people how they workeras@reddit
systemctl catshows where each fragment originates from, so that's possibly also useful for showing how they work.egorf@reddit
`systemdctl cat` is an excellent tool to solve a problem that would not exist without this very tool.
eras@reddit
Well, sure, but ultimately it gives the ability to have non-edited distribution-provided basic service configuration in /lib, while the user-modified configuration remains /etc, and they are combined in a common way, allowing packages to modify the default configuration without introducing merge conflicts in your custom service file configs.
I mean, what's really the difference compared to having configuration files in /etc in a way that they only list how they differ from the defaults? This is really how many applications work in the first place, except the defaults are inside the executable code instead of files. Can't grep those either.
It's really just too bad that not all applications use the same structure for configuration.
egorf@reddit
So let's store all our configurations in systemd and anyone who disagrees can just f off.
-this is the general attitude I sense from the systemd folks.
Irony aside your argument is valid. And I wouldn't say that sysv was ideal. Far from it.
But systemd is farther.
EverythingsBroken82@reddit
Time for systemd to implement systemctl grep whatever :>
egorf@reddit
don't give them ideas.
egorf@reddit
> Also, Lennart Poettering was just famously hard to get along with
BTW did he grow up by now? He must have been. Time has passed.
Although I can still see lots of that attitude in the current systemd packages (systemd-resolved comes to mind as an exemplary offender.
egorf@reddit
> You have to use journalctl
You probably don't. Text logs are still there.
Default ubuntu still writes text logs, so one of the things I immediately did on a fresh instance was `apt purge systemd-journald` (iirc). Unfortunately, systemd team was too well aware of that possibility, so with recent Ubuntu you no longer have an option to remove the tumor.
So, either carefully disable journald (systemct stop, mask, disable on a bunch of services - this is what I do) or just ignore the crap.
sparky8251@reddit
This... Isnt even a systemd thing? deb packages have an entire dang DB of options their pre/post scripts reference. Had a problem at work the other day where I couldnt figure out why grub was installing its bootloader to /dev/sda after i moved it to /dev/sdc to fix space issues for the OS upgrade. It was a problem because grub updated enough between 20.04 and 24.04 to make it so the 446 byte bootloader program was incapable of loading the newer version of grub in /boot. Turns out, after MUCH digging... the config option was stored in a binary format in a giant dpkg database and the sole way to change it was
dpkg-reconfigure grub-pcNocturneSapphire@reddit
grep whatever /etcwill find the configuration of whatever.tail -fed. You have to use journalctl, which doesn't quite do everything the old textutils tools could do (though maybe it handles huge log traffic a bit better).For example...?
Yeah I'd like an example of this one too
That's not an example
ayekat@reddit
That's new to me. Could you point to something in systemd where the configuration is in binary format? Logs, yes, but config?
I think this is very subjective. I personally think systemd's various
…ctlcommands are much more convenient and easier to deal with than whatever archaic shell pipelines were necessary to get some meaningful info out of the system before.I don't quite see what point you're trying to make, would you mind elaborating a bit?
Rare-Page4407@reddit
They can't, it's a lie.
Rare-Page4407@reddit
that's a crass lie. Everything is configured with text files, and symlinks.
RedSquirrelFtw@reddit
I find it's just unneeded complexity. I guess part of it is my unwillingness to learn it, but the old way just worked fine. For a desktop OS, I couldn't care less what it's doing under the hood but for a server I prefer simplicity, like text based log files, simpler commands, etc.
derangedtranssexual@reddit
The old way didn’t work fine
johncate73@reddit
Funny, I'm using PCLinuxOS right now, which still does it the old way, and it's worked fine for many years.
I can live with systemd if I have to--my wife runs Mint and I put her on it when she left Windows--but yes, the old way still does work fine.
blebaford@reddit
curious why you directed your wife to Mint rather than PCLinuxOS?
btw is the source code for PCLinuxOS available anywhere? I haven't found it which is a bit concerning.
johncate73@reddit
Because my wife was 57 years old at the time and had used Windows forever, and the Cinnamon Desktop was easily configurable, moreso than Plasma or MATE, into a UI that was easily recognizable to her. She say down at the new desktop machine I built her and completely understood everything immediately. PCLOS, while it is simple, is not as simple as Mint Cinnamon is. That is what I recommend to all new users coming from Windows. (Both of us prefer the traditional desktop layout; Kay didn't even like Windows 10 and was very happy to have Cinnamon configured like Win 7. My desktop pretty much functions like Win98, because that is how I like it.)
I have considering switching her over before, but if something isn't broke, why fix it? Like I said, I am not a zealot against systemd, just not a fan of it. And I have experience with several distros, and PCLOS has just been my own favorite for various reasons.
I don't know where the source code might be, but no one's ever accused Texstar of hiding anything, and the distro has operated for 21 years. It might be on their server at NLUUG or you might need to ask them. I can't imagine anyone's wanting to build PCLOS from source anyway.
egorf@reddit
Yeah, cron did not work fine for decades; sudo did not work fine for decades; ntpd did not work fine for decades. Obviously, this software is old and appreciated by old people only and therefore must be rewritten.
derangedtranssexual@reddit
I was more talking about how systemd is much better than all the init systemds that preceded it. I don't really get your complaint tho if you like cron or sudo or ntpd then use it.
Resident_Quiet_1517@reddit
I'm with you, but let's be honest, init scripts were redundant and could be quite clunky too. Just a clunky that we were used to :).
But yeah, text based logs FTW even if it's a little less efficient to parse and filter.
blebaford@reddit
redundant how so? the shell is not going away so adding another syntax to configure services seems like the redundant part.
cyphar@reddit
Folks who don't like systemd are an outspoken minority and most of the arguments are philosophical rather than technical (systemd has made mistakes of course, but people rarely hate a project because of bugs -- even post-Heartbleed OpenSSL wasn't really "hated" in the same way systemd is). For instance, I don't think anyone actually dislikes systemd's way of managing services (which is based on MacOS's launchd design) -- in the early days, folks used to pretend they preferred Upstart but we all know that was just cope. Writing buggy and overly-complicated shell scripts to manage system services always sucked and everyone who was honest with themselves knew it.
The short version is that the systemd project is trying to solve the problem of modernising Linux so that it has unified APIs for managing the system. (The argument goes that) this goes against the Unix philosophy of everything being completely modular. While modularity is useful for quite a few tools (and the Unix philosophy really was a breath of fresh air in operating system design in the 1970s which arguably was the main reason why Unix won over other systems), the lack of unified systems for managing system resources means that every tool on your system has a bespoke mechanism for managing it (configuration files, socket protocols, general daemon management) and people rewrite tools often enough that you end up with many generations of the problem being solved in different ways that make system management even more difficult. None of these problems existed in the 1970s so it's unsurprising that a philosophy born of the 1970s doesn't help much with solving it. And it should be noted that every tool having a bespoke way of managing it goes against the idea of modularity -- these tools aren't really modular if all of the management is some custom thing that you can't easily swap tools.
To be fair, a lot of the problems that systemd is trying to solve are related to desktop Linux. It should be noted that some of the most famous critics of systemd (Bryan Cantrill comes to mind) feel that desktop Linux is a waste of time and that MacOS has always been the future of Unix on the desktop, so to them the idea of solving these problems is also a waste of time and thus systemd is a waste of time that is overcomplicating things for no good reason. I like using desktop Linux and so I feel these arguments are just defeatist.
It should be noted that I'm definitely not a systemd fanboy. I've had plenty of disagreements with systemd folks, but I think a lot of people just think of systemd as an init system and nothing more (rather than a larger project) and so the reasoning for their dislike is based on a misunderstanding of what problems they're trying to solve and so they think everything is just "meaningless overreach".
sbart76@reddit
I am one of those people. I have written it in a comment to a different post already, so I'll just quickly recap here.
I maintain a bunch of PCs in a computer lab at my Uni. Dual boot with windows. Students do weird stuff on windows, which is not bothering me, except the clock/timezone change. After booting Linux most of the PCs are out of sync, SLURM cannot start on them. The solution is easy on OpenRC - running ntpdate before slurmd starts.
systemd, however, understands before/after differently: initiates the ntpdate service, and proceeds directly to slurmd service, without waiting for ntpdate to complete. You need to use waitfor target, what makes all before/after counterintuitive for me.
Yes, I agree, systemd boots faster, but most of the waiting is when clocks are synced. I agree, that my usecase is specific, and for a typical user is irrelevant. Also I never encountered a bug in OpenRC (which is not written in bash).
Yes, I am aware I'm a minority, I don't think I am outspoken though, and my arguments are both: technical and philosophical. In my previous comment I got a lot of downvotes from people saying "this is what before/after is for". No, it doesn't work like that. I understand systemd solves a lot of issues, but in my view OpenRC does the same and is way more intuitive.
Hikaru1024@reddit
This reminds me of a historical problem I had early on where systemd was not waiting for fsck to finish before trying to start services... Which meant if something went wrong, or fsck needed to check the disk, the result was rudely sprayed error messages everywhere hiding the fsck information, including important helpful messages like telling me to type in the root password to login and fix things.
I am... very disappointed to hear that even to this day systemd is still easily prone to race conditions.
semi-@reddit
I'm unfamiliar with OpenRC but I suspect its really easy when you're just dealing with those two services, but much harder when you have many services only some of which need to wait for a synced clock. Or does openRC not parralelize startup of services?
With systemd.. you can just use time-sync.target (see: https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html#time-sync.target )
Kwpolska@reddit
The clock/timezone change is very trivial to fix without requiring an NTP sync on every boot. You just need to make the two OSes use the same way of storing time in the hardware clock. Nowadays, telling Windows to use UTC for the hardware clock works reliably: https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows
sbart76@reddit
I'm only maintaining Linux on these machines. Windows admin is a windows fanboy, and would be happy to get rid of Linux whatsoever. I'm on my own here. I know. Childish. But thank you, I'll ask him.
Kwpolska@reddit
It's just a single registry key, shouldn't be a problem to get it through. And if it is, you can also make Linux interpret the hardware clock as local time (although it's claimed to be unsupported).
sbart76@reddit
Sure. But the bigger issue is that the students are allowed to do things like managing the clock and the timezones. I never know what I will find out next time I boot...
Kwpolska@reddit
That sounds awful. There is no reason why any student would need to manage that on a school computer.
jr735@reddit
Not a solution within systemd, per se, but where possible, you can actually install the ntp (now called ntpsec) package. That tends to get things fixed up before it matters for you.
sbart76@reddit
Yes, I am aware. But it seems an overkill for just that. Thanks for the suggestion though.
jr735@reddit
It certainly is more than is necessary; it's just been a habit of mine since even before systemd.
dagbrown@reddit
So a quick look around tells me that there's a target called "time-sync.target" which is specifically for your exact situation. Putting the line
in your service file for SLURM, in the
[Unit]stanza, will ensure that the system clock will be in sync before the service starts up.Perhaps you should mention this to the SLURM maintainers if it's that important!
Which is all to say, it's not systemd's fault that you haven't gone to the trouble of learning how to use it before saying it doesn't work the way you like.
sbart76@reddit
Please read again my initial comment, but this time with understanding. This is how I was thinking it would work after a quick look around, but it does not. And yes, I have gone through the trouble, and have more experience in it than you.
ascii@reddit
So your gripe with systemd is that it by default starts things up in parallel, that you need two specific services to start up in serial on some machines you manage. You go on to say that systemd in fact has a syntax for specifying that two services need to be started up in serial but doing so adds one line of extra configuration which you find unacceptable. You readily admit that starting up services in parallel leads to huge performance improvements, but you don't think that performance improvement is worth the one extra line of configuration.
I can't help but feel like you are desperately grasping at straws.
sbart76@reddit
Please read again what I have written :) or better - try to do it yourself before replying, because contrary to you I have gone through this, and I know what I am talking about
It is perfectly acceptable to add more than one line of code to make things work. I don't care about performance improvement of about 5 s, I boot these systems once a day. But is systemd it is not like that. It takes more than adding one line of code.
markusro@reddit
And that is what is so infuriating. You point a clear flaw out and you got told read the docs, it is not meant to be done like that, etc.
Systemd is not that bad, most parts I like, but it does not solve all the problems it promises to solve. Also systemd encroaches IMHO to much on territory served by other specialized tools. These tools may be old but they are used since years and the flaws are well known.
Why does systemd needs to implement its own systemd-timesyncd.service, systemd-resolved.service, etc.? There are already well established tools available, may be fix the shortcomings first (which is very difficult. I do not say that's easy) before you write a new service.
SwizzleTizzle@reddit
Change ntpdate's service
Typetooneshotsbart76@reddit
I'm pretty sure I tried it, the only way that I found was to use
WaitFor. I'll have a look again tomorrow.cyphar@reddit
I suspect the issue is that the ntpdate service is configured to be "running" once the daemon starts and not once synchronisation is done. I don't know if you've already tried this, but if the ntpdate service has an
ExecStartPostwhich waits for the sync to be done, thenAftershould work the way you expect. You can add this with a vendor drop-in, so no need to modify system files managed by the package manager.The decision to package ntpdate like a regular daemon without a custom
ExecStartPostis a decision by the package maintainer and there are good arguments either way (waiting for an NTP sync during boot doesn't make sense for most users, but this does cause issues if you do care).JockstrapCummies@reddit
This is why, despite being an enjoyer of systemd, I'm very sympathetic of the naysayers.
Time and again we've seen the philosophical approach proven correct in the young history of computing. The purely technical argument more often than not results in an apparent improvement that turns out to be more harm than good. Cf. the whole craze about cloud, or "web scale" earlier.
kqadem@reddit
May you elaborate?
We provide an internal cloud platform for development teams that takes out the complexity for managing such. We did journeys how long a team would need until having their first service / containerrunning in the cloud. With our offering they achieve this within 30min and get security compliance and high availability on top.
In average, the response from the teams is that by using our offering, the are able to save one full-time engineer, who otherwise would try to take care of the infra, not mentioned getting security compliance.
As of this week, more than 250 teams use our platform worldwide, 150 of then are already customer facing / live.
We are a group of 10 cloud dudes.
let me see how you do the same on-prem.
Earthboom@reddit
There's pros and cons to your business model. Certain businesses benefit as you've described. The average consumer does not.
Ease of use, infrastructure in a box, parts already purchased and working flawlessly, no overhead, click a few buttons and you two can have whatever system you need in a matter of minutes, just exchange dollars.
Makes sense.
The average user doesn't really benefit and even some businesses who think they would benefit, don't but just purchase into it because they think it's the future. The employees wonder and scratch their heads asking themselves why they have to login twice.
It's a great technology, but it's for niche cases and it's being marketed to everyone as a must have. It's a business model that isn't organic and it's instead forced because it's not making returns naturally. It's an artificial need for lots of cases.
One simple on prem server with a hypervisor, one dude who knows his shit, and sky's the limit for businesses 100 users and less.
Anything more and it gets complicated quick. Now you're talking a federated server setup, nodes, redundant backups left and right, VPN setups for various offices, and that's where the cloud comes in.
Makes all that pain go away.
... For those cases.
kqadem@reddit
Going on-prem is bet into the future. You are investing capital into hardware and you need to pay someone to maintain that hardware. Also you're investment does not scale with your business demand.
Cloud switches this capital expenditure to operational expenditure. You now only pay for stuff that you also consume. Does that safety it come with a price tag? Hell yeah. Directly compared, managed cloud services are more expensive. But you don't have to worry about the required skills to maintain such services. Or you want to try out Serverless for a POC the next 4 weeks? You can either hit a button and start, or you can hope your poor dude knows how to setup such a thing on-prem. And if not, you gonna hire someone for 4 weeks? How fast you gonna find him?
Earthboom@reddit
Lots of industry professionals are seasoned with certifications and years of expertise. Finding some dude is easy especially because their expertise transitions we'll into cloud infrastructure.
Buying a server once will serve you for 5+ years easily if not more which is enough time for your business to scale. That's several thousands of dollars saved versus cloud. On the event you grow that big to warrant the cloud the cost of doing the cloud would be justified at that point because on prem doesn't scale like the cloud does.
LaurenceDarabica@reddit
Cloud is just a very pricy way of avoiding a system admin hire. You can go the VPS system route as well - all the perks of cloud for a fraction of the price, admin excluded.
Cloud is basically a fast way of releasing something that will never be successful. If it is, you're in for a world of hurt.
jimicus@reddit
Do you work for the same company as me?
kqadem@reddit
no
Earthboom@reddit
I'm convinced cloud and server less is just a get rich quick scheme. You're giving up compute and paying for it while corporations use it as an excuse to purchase more resources, charge more, and create an artificial demand no one wanted or needed.
Instead of making consumer hardware, now they're making unified ubiquitous enterprise hardware and it's easier on them. They recoup the costs by charging you for what was already yours and free. You just had to pay for electricity.
Now you pay for electricity, internet, and the per minute / hour usage of compute to do the same task with only marginal / niche benefits that select few people can argue.
tooclosetocall82@reddit
How exactly do you run a server without internet? You’re also ignoring the costs of standing up a data center (cooling, fire suppression, real estate).
Earthboom@reddit
For a data center yes, cloud is better. For a single on prem server, nah. Just stick it in a room somewhere with a ups.
Brillegeit@reddit
They probably mean network throughput.
tooclosetocall82@reddit
Idk what they mean. To manage an aws infra I just need a basic internet connection I already have. To run a server out of my garage I need a much fatter pipe that may or may not be valve to my garage. If it’s not I’m looking at renting somewhere that provides that pipe. I guess if all you need is something on the lan then yeah running a server might be more cost effective. But anything external probably not.
crazyguy5880@reddit
Yes but you have a lot of companies like mine that have their data centers and fat pipes already and they keep building stuff in AWS, Azure to be trendy and “hybrid” while becoming dependent on the “easy” proprietary services and charging their customers more
piesou@reddit
No, quite in the contrary: only the technical approach is the valid one.
What people forget is that you need to evaluate those technical approaches and see if they benefit you. People don't do that properly or get overruled by management/peter principled tech people. In my career so far, every single technology stack has been pushed down to engineering from the top because an executive had a meeting with Accenture or SAP consultant.
Then you got AWS wich wants to sell their services. The more they make it seem like serverless is a good choice for your business, the more money they can make, so there is a giant push towards serverless and cloud for the most idiotic reasons.
Misicks0349@reddit
I mean I agree that a philosophical approach is nicer, I just think that philosophically the systemd haters are (mostly) wrong \:P
Business_Reindeer910@reddit
I think you'd have to split up which parts you're talking about.
When it comes to the init system part specifically, it's gonna be a ton easier going from a declarative unit file back to some shell script or any other type (like to say gnu shephard where services are likely defined in guile) than it was getting them into systemd in the first place.
No-Bison-5397@reddit
The one things about systemd that I think is pretty clear is that there are too many programs that have it as a dependency... but that's on the programs, not on systemd.
vetgirig@reddit
One thing you might ask yourself is; Why do the programs have dependencies with systemd ?
Is it because systemd requires that so programs work well with systemd ? Thus systemd forcing them to depend on systemd to work well with systemd ?
No-Bison-5397@reddit
The xz backdoor exposed a few needless systemd dependencies which were removed.
That's clearly on the developers of the applications.
sparky8251@reddit
Was actually patched in by the distro, the application itself had no such features.
No-Bison-5397@reddit
Ah yeah good point, sorry memory fault for me. But it still stands that that’s on the distro.
sparky8251@reddit
Yeah, agreed... Either way its not good it happened.
RangerNS@reddit
systemd isn't forcing anyone to do anything. If you don't want to use it, don't use it.
vetgirig@reddit
Saying that you are not forced to pay the toll and drive on the toll road - you can just build your own road is not really an option for most people. They cant afford to build their own road.
RangerNS@reddit
The other roads still exist. If you want your application to not support systemd, then dont support systemd
ayekat@reddit
I would guess that many applications now offload some of the work to systemd that they would have previously had to (more or less poorly) reimplement themselves.
The first thing that comes to mind would be just any software that has a client-server architecture, which can make use of systemd user services. Also the whole login session tracking (thinking of the GNOME/KDE stacks) is probably easier to do with some unified system-provided API.
But also in terms of "dependency", one has to check which part of that is simply distro maintainers declaring systemd as a dependency for something because it's been integrated to run with systemd (e.g. unit files configured and shipped with the package).
_oohshiny@reddit
As the XZ attack showed, systemd's idea of an external interface was "just include the library, now it's an internal interface, no worries". We saw how secure that (almost) turned out to be.
aqjo@reddit
Like libc.
Dense_Impression6547@reddit
To be honest, systemd goes over the fence of strict service management on some case. I have to give give the point to haters when they says that systemd should not have imbedded services like its own NTP client, sockets management...
I'm not saying it's a bad thing, but it's definitely out of "do one thing, and do it well " this make the tool opinionated about stuff others than how services should start and stop.
A_for_Anonymous@reddit
Not only it has a ton of junk for any random shit Poettering wanted, and solves problems he and only he had, but it tends not to work and it tends to be pushed to distros years before it's stable. systemd-timesyncd is still buggy af in Debian 12.
All in all it's 50+ modules, MILLIONS of LOC of utter Poetterware crap full of CVEs in PID-fucking-1 when all that was needed was to start daemons, because some Windows lover wanted to build an OS.
Dense_Impression6547@reddit
Shiiiiiiiiit, show them how good quality code should look like. Go and fix their incompetence.
TheOriginalSamBell@reddit
that's all up to your distro people what they include and what not 🤷♂️
A_for_Anonymous@reddit
You keep repearing that lie, but most of the worst, most opinionated, Windowsy Poettering crap is required, such as the ugly journald and its regarded journalctl.
TheOriginalSamBell@reddit
yikes
Leliana403@reddit
This bullshit yet again...
These services are not "embedded" in systemd. They are separate binaries that are in no way required to run systemd PID1. If you don't like them, disable them. It's that easy.
Please educate yourself before spouting misinformation you heard from somebody else who is just as uninformed.
elsjpq@reddit
Another big part of it I think is that even if you agreed with the goals of the project, you didn't like way that they solved the problems. An easy to understand example is binary logs instead of plaintext logs. Design decisions often felt quite opinionated rather than deferring to the preferences of the user
Coffee_Ops@reddit
Text logs are binary logs. This has always been a silly argument that fails on even the most cursory inspection.
What's that you say, at least there are ASCII tools on most Linux distributions? Well guess what, there are also journald tools on the overwhelming majority of distributions.
Pyrotech72@reddit
This may be an oversimplification, but everything in a computer is binary, anyway.
piesou@reddit
I think the context got lost. Systemd is developed by Red Hat first and foremost which often runs on thousands of machines. If you develop software on that scale, there is always a trade off when designing the most basic things. Binary logs could have solved not only a performance problem and also a security one which might have been important for certifications.
You can see the same when looking at Docker which refused to merge systemd integration PRs. This was so important to RH and their customerbase that they've essentially supplanted Docker with tighly integrated Linux tooling (Podman/Buildah).
wintrmt3@reddit
Database write ahead logs are for machine consumption, not for humans to read, your argument makes no sense, the only relation between the two is that they are both called logs.
piesou@reddit
Your hobby machine won't benefit from binary logs, true, but many systems in productions have gigabytes of logs. Yes, people do actually run software on those.
silentjet@reddit
I've been developing embedded devices for years (based on CortexA socs). binary logs are useless and journald is the most unreliable in production and useless in dev and debugging logging system, it is just a matter of fact. syslog/rsyslog is a magnitude better. While I'm from the team sysv and devuan, I understand an intention of the systemd, and the problem it tries to solve. The problem is systemd does it quite badly and inefficiently. Reimplementing osx system manager was a bad idea, it does not fit such a diverse ecosystem like GNU/Linux one...
fripletister@reddit
You're the hater that was previously mentioned in the top comment of this thread.
silentjet@reddit
No, I'm not. Just working on a daily basis with systemd on PC, servers, embedded products, everywhere... So I'm a hardcore user, no more no less...
piesou@reddit
I think it goes without saying that embedded and server are entirely different areas. In embedded, you are likely running musl, a cut down linux kernel and busybox. Without glibc you can't really use systemd anyways.
silentjet@reddit
Yes, and that is a problem. most SoC vendors deliver their bsp based on systemd. Reworking it fully is quite expensive, especially considering the time to market is so short nowadays and software complexity is high as a sky...
kinda_guilty@reddit
It does though. You just don't like it. Maybe the trade-offs they made were slightly off from what you want. But it is just better than what came before. Maybe something else will come forth and supplant it, but that's doubtful.
silentjet@reddit
I do not agree with your statement, i'm objective in my judgement of the systemd(i hope so). So it is incorrect to say that systemd is better, because there was no similar software, so it is not better, just it is first of its kind in GNULinux. And also the way how systemd integration into the OS had happened is suboptimal. The biggest problem in my opinion is that systemd tries to solve problems that do not exist for most of the PCs and laptops. At the same time it doesn't really solve the corporate problems as well, but imo on a good way to do this...
wintrmt3@reddit
Nice condescension, real systems shove their logs into greylog or something similar so you can see the whole cluster, and journald binary logs aren't appropriately indexed for efficient search, you don't seem to understand this topic very well.
fripletister@reddit
Define appropriately indexed? Cause I think you're misinformed.
wintrmt3@reddit
It only has simplistic field indexes, no full text search index.
fripletister@reddit
Fair
Eu-is-socialist@reddit
And that should explain the "love" and rapid adoption .
Leliana403@reddit
"Everything I don't like is a corporate conspiracy."
Doesn't it get boring thinking the whole world is out to get you?
Eu-is-socialist@reddit
Nope ... not quite everything ... but a lot of things ARE !
Leliana403@reddit
I'm not the one going around spouting baseless conspiracies darling.
Eu-is-socialist@reddit
LOL ! You were the one that told everyone who is DEVELOPING Systemd !
Leliana403@reddit
You should rewrite this comment when you're not frothing with rage, it'd probably make a lot more sense.
Mysterious_Bit6882@reddit
Fun fact: The RHEL side of Red Hat (i.e., the money side) originally didn't want systemd, and wanted to stick with Upstart (Canonical's init system that died from the usual Canonical problems of launchpad and weird technical decisions). It was the Fedora side (many of whom don't even work for Red Hat) that pushed systemd hard, and eventually convinced the RHEL side.
Eu-is-socialist@reddit
LOLOLOLO
Who funds fedora?
light_trick@reddit
That argument has always been weak though. If logging is important then you're already doing something else - i.e. forwarding them somewhere else. If you want text logs on disk then well...you can do that too, all the major logging systems have journald integration.
For the argument to work you end up with this demand that systemd should solve a problem which, if the user found important, they would be specifically solving another way, and also requires some very specific types of bugs to exist in systemd to even be a problem (i.e. the way systemd archives potentially corrupt logs isn't wrong, but a ton of people complaining about logging also don't know how to drive journalctl to look at uncleanly shutdown logs).
egorf@reddit
> actually dislikes systemd's way of managing services
systemd as PID1 is great and so much better than any init system before. I used to be a hater of systemd - well, I still am - but PID1 is a good thing.
> (which is based on MacOS's launchd design)
Launchd on macOS uniquely combines the disadvantages of both sysv and systemd approaches into a single impossible-to-use package. I run a few server side macs in production and launchd is beyond saving.
> -- in the early days, folks used to pretend they preferred Upstart
I would go back to upstart in a heartbeat. In less than a heartbeat. Yes, I like systemd as PID1, but the temptation to get rid of both the cancer and all its metastasis is too big.
> Writing buggy and overly-complicated shell scripts to manage system services
Agree. Then don't. The ability to wtf in bash is a feature but not a requirement.
> The "hater" argument is that this goes against the Unix philosophy
While I fully agree, it's past the time this argument has merit. It's too philosophical and a whole new generation of sysadmins grew up who have only seen systemd and not a modular unix system. So, moot.
IMHO a more relevant argument is that systemd folks tend to think that there is only a single opinion and it's theirs. And everyone else can just fuck off. That attitude is plaguing most of the systemd packages I have seen.
> the systemd project is actually made up of many different
yes, but coming with a consistent attitude as learnt from one particular prominent figure.
> To be fair, a lot of the problems that systemd is trying to solve
....just don't exist. We have used cron for *decades* . We have ran sshd daemon in background for *decades*. We typed and called sudo for *decades*. And guess what did not take place during all those years? That's right: no one complained. Those things were perfect.
Heck, even binary logs are a solution in search of a problem. Again, text logs with rotate were a perfect solution for decades and still is today. There is absolutely nothing that journald brings to the table for a regular server ubuntu instance.
> they think everything is just "meaningless overreach".
I am pretty sure it is. I also tend to think that systemd projects are more like a job security for folks at Red Hat, because if they don't destroy another well-known tool, they will have nothing to do.
Ytrog@reddit
As someone who isn't actively configuring deamons (except maybe SSH), just merely using Desktop and CLI scripts what are the differences between Init, Upstart, and Systemd?
When I began Linux Upstart wasn't even a thing. I just never had any reason to bother with them, however my curiosity is piqued now. 👀
Brillegeit@reddit
From someone who also isn't actively configuring daemons:
sysvinit:
It works, but either requires use within the default scripts or under the management of competent admins. Adjusting the system often requires that the admin understands code and can write a bespoke solution. Slow.
Upstart:
Allows the OS to quicker come to a state where the user can log in. Changing the behavior of Upstart services is easier and portable between versions and systems. Doesn't require legacy software init scripts to be recreated in new language.
According to Wikipedia ChromeOS is the last major distro using Upstart.
systemd:
Where Upstart is a better sysvinit and backwards compatible, systemd comes with a entirely new environment that collectively does 10x more than any init system before, while also requiring that all service management is rewritten as systemd units. In the most extreme cases you can kind of describe it as an intermediate OS level in between the kernel and userland.
The simplest way of explaining controversy is that you have Lennart Poettering who doesn't really collaborate well, doesn't like POSIX and doesn't care about compatibility with BSD, and think one of the biggest problem with Linux is that there are too many distros and too much alternative software. One day he comes down from the mountain with 1 000 000 lines of code and proclaim that this is now the new uniform core of all distros.
Some said "yes please, we needed this", others said "wtf, we don't need this!", some said "we hate you Poettering, and Pulseaudio and systemd as well rabble rabble", some said "do we really need to replace 500 lines of scripts and a dozen stable and mature services with a brand new framework of tools?", but most of us didn't notice any difference at all.
Ytrog@reddit
Thank you. You explained it well 😁👍
die_dingens@reddit
> To be fair, a lot of the problems that systemd is trying to solve are related to desktop Linux.
Systemd aims to solve many issues related to desktop Linux, but unfortunately, it often disrupts the functionality and stability of server Linux.
cyphar@reddit
systemd made managing services on servers much nicer than alternatives (I think a lot of people forget how broken things were before declarative service definitions), so this isn't universally true even if you just consider the original project.
To play devil's advocate, I think the binary logging thing was a fairly large mistake despite whatever benefits they argue for it and that mostly impacts server admins. But it's not true that every win for desktops is a loss for servers (there are plenty of counterexamples).
WjU1fcN8@reddit
It's very important to not that the UNIX philosophy supposed that the 'many small tools' would be developped in a single repository, as a coherent whole.
Only when GNU came about they created this 'many different projects' aspect, which is not aligned with the UNIX philosophy.
People that don't like Systemd might talk about UNIX, but that's only because they don't know it.
1EdFMMET3cfL@reddit
MacOS is fine but unfortunately I have no firstborns to mortgage in order to upgrade my RAM from 8gb to 16gb.
subhumanprimate@reddit
Great comment but desktop Linux is a waste of time 😜 they all suck and Windows dies it better. Leave GUIs to the people who've pumped millions into the user interface psychology and Linux can handle the real computation at scale with decent stability
_a__w_@reddit
It is probably worth noting that Cantrill’s position isn’t without some level of experience here. Solaris had already shipped SMF in an official release before Apple’s launchd did. So a lot of those debates (and the big one that sticks out in my mind was whether init should launch SMF or if SMF should replace init) had already happened. Internally, IIRC, SMF was added very early on in the WOS builds. I think if it hadn’t used XML (which I blame the Java folks and Tim Bray for) we might have seen it adopted instead.
dagbrown@reddit
It doesn't use XML any more than launchd does.
Which is to say, yes, there are XML files that you feed into it, but internally it's all a binary database which you can manipulate with purpose-built tools (one of which imports and export definitions in XML format, but they could just as well be TOML or JSON or something. It's just that XML was in fashion at the time they were created).
One of the huge improvements that systemd made over launchd and SMF is that its configuration is text, the way the Unix gods intended. They get bletcherous points for looking like Windows 3.1 INI files, but since Windows seems to have abandoned those sorts of things altogether in favor of (yay!) blobs of binary muck, the Linux folks can take advantage of their work and use their format for good, not evil.
eras@reddit
How does Windows not using something affect the ability of Linux folk being able to make use of it?-) Doesn't seem like a very helpful attitude! What other nice things is Windows using we "can't" due to the fact that it's using it..
Though you probably were just kidding there, perhaps it could be real phenomenom.
dagbrown@reddit
That was just light-hearted commentary on Windows seemingly abandoning the INI files that it used to live and die by, only for Linux to adopt them en masse.
_OVERHATE_@reddit
Fucking lmao, so basically mental people that shouldn't be taken seriously at all
mok000@reddit
That's weird, macOS also doesn't use init scripts, it has launchd, which actually inspired systemd.
cyphar@reddit
It also has unified management for a bunch of other parts of the system (which also arguably inspired bits of systemd-the-project). I think the main argument is that systems are either "desktop systems" or "server systems" and appeasing the desktop folks will make Linux a worse server system.
Aside from being a somewhat extreme black-and-white view, history doesn't really agree with this. Even if you ignore the systemd example (which I think has proven that you can make both sides much happier), there are other example. From the kernel side, a lot of the work went into power management on Linux to make servers more energy efficient ended up being incredibly useful for handheld devices like Android. Same goes for tools that were traditionally designed for securing servers (namespaces, LSMs).
mok000@reddit
The init system, for both desktops ("workstations" like SGI's) and servers worked fine when there were single vendors responsible for the entire system, and when customers would buy all software from that company. But in the Linux world, where we have distros and packages maintained by thousands of developers, it is near impossible to slot your package's init script into
/etc/initwithout interfering with something else, or perhaps starting your service at a stupid time. That is a problem not matter if the computer is a server or a desktop, and systemd solved this problem. I know you are not arguing against systemd, I just wanted to highlight the absurdity of the server argument.praetor29@reddit
Insightful writeup, thank you!
Dramatic_Object_1899@reddit
Because in spite of all the talk Linux enthusiasts are quite resistant to change.
Nostonica@reddit
The vocal ones are, people going on about the traditional desktop make even less sense.
blebaford@reddit
please explain the default behavior of alt-tab and alt-` on gnome
egorf@reddit
At the unix system level there is quite a few tools that are done. Forever. They are perfect with no need to remove or add anything. Like cron, sudo and sshd daemon listening on a port.
There was no need to disrupt those.
So sometimes resistance to change is the right way to react.
sidusnare@reddit
Scope creep.
I like systemd as an init system, but unfortunately it's taken over so much more. I'm even okay with the logging. But taking over the resolver, changing the fstab behavior, and so on is just annoying.
bripod@reddit
I'm salty about the resolver that doesn't work the way it used to, pulling DNS servers from a list in order. Now it just randomly selects one which breaks internal hosts sometimes so I have to manually override it.
WjU1fcN8@reddit
You're comnplaining because systemd solved a bug you relied upon. Do DNS properly.
sidusnare@reddit
It's a bug that could have a much better solution. Replacing a file with a process is just not a good fix.
WjU1fcN8@reddit
Don't do split-brain DNS, that's the solution, split-brain.
sidusnare@reddit
The problem is it always hits the first entry and doesn't go to the next resolver until the first times out. Resolution should be even across all resolvers. Go could just update the resolver library to choose
resolver = mod(now(), $number_of _resolvers). Some people want to introduce randomness, but it doesn't need to be truly random, just balanced across all options. The blocker on making it random is trying to share the randomness or every instance being independently random.sparky8251@reddit
Not a bug, but a lack of specification. Every other resolver works that way because the specs for a resolver dont demand you query all of them all at once.
Not that I personally dislike resolved... I love it. I love its diagnostic tools as well, especially since I make use of mDNS as well as DNS at home and it can handle both protocols at once.
WjU1fcN8@reddit
Other way around, DNS specifically forbids it.
sidusnare@reddit
If the order of entries in /etc/resolv.conf causes problems, your problem isn't the content of /etc/resolv.conf.
egorf@reddit
systemd-resolved is easily the worst systemd project and that's a hard competition with so many strong contestants.
I feel like systemd-resolved has been created to be removed by the sysadmin after installation, just like transparent peel from screens of new devices after unboxing.
Running systemd-resolved on servers is plain impossible.
sidusnare@reddit
I'm just fundamentally against replacing a file with a process. It's a bad solution to a problem I can't identify.
redoubt515@reddit
egorf@reddit
> 1. [] nothing in Linux is forced
Sure. Like you can practically run a non-systemd distro today. No, you cannot. Not anymore.
Sure, nothing is forced. Have you ever tried to disable a systemd service for days trying to figure out why it's still up and running?
Sure, nothing in Linux is forced. Try to change a nameserver with systemd-resolved physically present on your OS installation.
> 3. Learning
I mean, cron worked perfectly fine for *decades* and now you tell me systemd timers is the only right way to go and my ways are old and outdated?
I have to learn journalctl instead of the plethora of text tools that are the very thing that made unix what it is? Okay, but for what reasons? What journald brings to the table except bloat?
> 4. Probably some other valid technical reasons I'm unaware of and have never heard mentioned by systemd critics.
Of course. systemd is hated purely on emotional levels. Technically it's perfect and there simply could be no criticism, right?
Unlucky_Owl4174@reddit
> Sure. Like you can practically run a non-systemd distro today. No, you cannot. Not anymore.
You can. There are various distros that exist basically to cater to people like you. And if none of those suit you, you can of course try to do better yourself.
You are not entitled to demand others do work on your behalf. If you don't want to use systemd use a distro that doesn't use systemd. If none suit your needs make your own. You are not helpless. You are not without choices, you are just being open-source-karen
> I mean, cron worked perfectly fine for *decades* and now you tell me systemd timers is the only right way to go and my ways are old and outdated?
Again, the pretend-helplessness is a really unattractive and immature look. Not sure why you think its compelling.
Not only have I not told you to "systemd timers is the only right way" I don't even use systemd-timers, personally I use cron, because again... you. are. not. helpless.... you have choices, you are not forced. Use Cron if you want use Systemd-timers if you want. Just don't act like an infant about it, and try to stay a little more calm and rational.
96Retribution@reddit
Before I continue, the hodge podge of rc init scripts was an unmanageable mess. I lost work years on those things I think.
It re ordered command and service from the old system command Zero status provided after the command Overly complex and serious mission creep. Journalctl blah blah flags more arcane syntax Can’t memorize that mess.
We replaced a mess with a different mess. I read another Reddit thread that said things should be “stupid easy”. User space init tasks should be stupid easy, extremely efficient, and provide immediate info or status when being run interactively.
Lastly, at the risk of starting another topic, Redhat. I mean IBM being in full control of such a critical function with no viable alternative doesn’t feel great.
Resident_Quiet_1517@reddit
Overly complex. That's my main gripe. As an old sysadmin, I liked that a good chunk of my systems initialization was based on shell scripts and not compiled binaries. One mess I'm comfortable with vs another one I have to learn again and again because I don't use it often enough and all that.
I had recently a machine that died on me, so I wanted to analyze the logs on another machine, and IIRC I had to shave a couple of yaks because the binary log format had changed. That kind of thing really pisses me off.
That being said, we have to live in our time. As long as my distro of choice doesn't change core components like that every second major release, I can live with it.
egorf@reddit
> distro of choice doesn't change core components
They absolutely do. Ubuntu changes network init tools with every major release.
And after a 24.04 upgrade I have been pulling my hair out trying to figure out why the hell sshd listens on port 22 despite different port has been specified in sshd_config. I have been questioning my sanity after endless debugging of that issue, because `ps ax | grep sshd` shows sshd, lsof shows sshd, and it listens on the default port which is specified nowhere.
Turns out, systemd folks ate sshd for breakfast. It's the systemd who is listening on port 22 now, not sshd. And it's masquerading as "sshd" to make you feel rage.
Resident_Quiet_1517@reddit
That's why I mentioned it. Makes me a very grumpy old man. Oh, and have you looked at the partition layout of a fresh 24.04 install? I'm getting old, I tell you.
systemd listening to 22? We're full circle back to inetd.
egorf@reddit
> systemd listening to 22? We're full circle back to inetd.
I know, right?
But inetd is neckbeard old rust while systemd listeners are the new, modern, and right way of doing things, can't you see.
endo@reddit
These are my two biggest gripes about it.
When I run a command to start or restart or stop, I don't want to have to then run a status command afterwards to see if it worked.
art-solopov@reddit
But that was the problem, wasn't it? That it wasn't in fact super easy. That you had services that depended on the network being there, services that depended on other services being there, and everyone was just writing bespoke solutions on how to wait for these services.
GatitoAnonimo@reddit
As a Unix Linux sysadmin/devops engineer for 24 years now, I hated it for a while early on for all the reasons people will list here I’m sure. I even ran Devuan for a number of years. But I switched back to Debian years ago and quite honestly systemd isn’t too bad at all. I find myself using more every year.
egorf@reddit
systemd as PID1 was nice until bloat came to it as well.
It's the other things that are cancerous. No one asked for ntp rewrite.
heldain@reddit
From my experience, a lot of the hate is because it's not initd.
People i work with have been unix admins for over 30 years, and as a result can be opposed to significant changes.
egorf@reddit
As a unix admin for over 30 years, I hate systemd not because I am opposed to changes (I love new shiny things) but because systemd is a cancer. It's destroying things that were working perfectly (I mean it) well for *decades* just for the sake of doing it. So almost every time a new systemd project arises I am speechless... like... sudo has been serving us for many decades now, how could one even look into that direction? What's next, systemd-ls? systemd-echo?
But yea, I'm an old fart, what do I know.
nejnej25@reddit
For me systemd is okay but there are some components I hate like journald for logging and resolvd for nameservers.
Well I need to embrace changes since Im a sysadmin/devops, I still install rsyslog btw haha.
egorf@reddit
journald is for logging and resolved is for removing it from the fresh installation.
I still remove/disable journald as well and use text logs as long as they are there.
Mister_Magister@reddit
people who hate systemd are not actual sysops/devops but circklejerk that feels superior about themselves because they're not like the others. While if you manage servers systemd is 10000x simpler, easier to manage and easier to debug
egorf@reddit
I have been managing servers for decades. Thousands upon thousands of them. Large projects. So, a lot of circlejerking and superiority feeling, right?
I will never go back to sysv-init from systemd-as-PID1. I think systemd-as-PID1 is mostly a nice thing. I'd go back to upstart in a heartbeat. I think that initscripts were much more transparent and controllable way to boot a system and manage services. I think that other systemd projects are pure cancer and must be killed with fire from server side things. I am convinced that Linux desktop is impossible without system-as-an-ecosystem.
And yes, all those opinions are mine at the same time and yes they are self-contradictory. A love-hate kind of relationship if you will.
FlukyS@reddit
I'd sum up a big set of specific things that people give out most about is:
systemd names a lot of things systemd-something without them being real necessary for what systemd advertises itself to be. I think those parts should be considered separate and evaluated differently. Like no one really uses homed, homed seems actually quite good and I'd love to see it being used but the implication when you go on the systemd website is that it is part of systemd even though it is a separate project. Same goes for timed, journald...etc too, systemd in general should be specifically used to refer to the service handling stuff only IMO just to avoid confusion. I'd even be fine with just calling them timed or whatever and not systemd-timed which is what is called in docs.
This is a nitpick but kind of linked to 1 but it is something that I think matters a lot and that is systemd breaks quite a lot of UNIX design principles of make just enough to do a task and having system internals be file based in terms of interaction. systemd control runs through cli or dbus. Just for a hint at the implication here is for instance if you want to change the kernel setting for your CPU to performance, you can go into a file and change a value, most don't do that directly they will have an app or whatever to handle it but from a developer side of things that means you can change that value (if you have permissions for that task) with any programming language at any time. It is super powerful and doesn't require any other magic dance. Relying on dbus for IPC I think is something that I hate generally, I agree that apps should have ways of doing IPC to talk but dbus has pretty poor documentation and the tooling around it isn't really friendly. Like look at Python dbus libraries and you will find a few different options and none of them fun to use. If I had a magic wand I'd refactor dbus to allow JSON as well and I'd have a file interface as well just for write only stuff like settings handling or state.
Because systemd is quite strongly linked you can't hook into it at a lower level easily when there are things you want to do. A UNIX design thing as well is the idea of being able to chain things together for example the UNIXy way of searching logs would be doing some get logs command and then piping it to something else like grep to parse it, how journald does it is they built in their own grep into journalctl, sure that is convenient and I assume there is some performance reason for doing so but it forces you down a specific path. You still can do it the UNIXy way and pipe it but I'd assume most people will just use the command in the ctl but if that has a bug or doesn't do it in the way you like you are shit out of luck.
Mostly stuff to do with software design and nitpicky stuff from me on this but I think those are valid things to complain about generally. I'd say though the benefits of systemd, journald, timed, networkd...etc far outweigh anything said negatively about them. Like I'd prefer if it was more modular and had better interfaces specifically because I want to adopt it better but I still want to use it and still do use it.
helgaardr@reddit
Systemd-resolvd and -timesyncd are a shame IMHO
egorf@reddit
Yes, those two are the worst offenders, hands down.
mocam6o@reddit
I use systemd exactly as it is today. It would be horrible to think if everything was really just as you describe here.
FlukyS@reddit
Well to be fair one of my complaints is naming more than even the projects existing. To be fair accepting either XML or JSON wouldn't be a horrific thing for dbus to support, that isn't specific to systemd. And as for maybe have file interaction for control it wouldn't be impossible either in a way. For instance stop, restart, start could be done in a file interface by having the current state in the file, if it is changed then do that, so if the user changes from started to restart then restart and change it to started. That kind of thing would cut the dependency on a poorly documented API and at least give a fairly agnostic way of doing things. I don't think the idea is bad.
As for the last part about having separation, that could be done while still supporting the centralised tools and that one is probably a lot more minior a gripe compared to the first two.
70m4r30m0@reddit
They hate it because there were not here or they don’t remember what init systems there were before it. Author got so much personal hate. A very disgusting chapter of foss ecosystem
egorf@reddit
I remember init systems very well. Not just on Linux, but on other obscure unixes as well.
They did work. They were transparent. They gave you control.
And yes, you could totally make an incomprehensible mess out of it, which some maintainers totally did.
mocam6o@reddit
Nobody really hates Systemd. The fact that someone hates Systemd is a meaningless campaign initiated by someone. So far, no adequate anti-Systemd position has been found. My own desktop Linux is based entirely on Systemd - Bootloader, Network Manager W/ Wireguard VPN, DNS Resolver, User Manager, Home Directory Encryption, D-Bus broker, timesync and others. Perhaps everything that is possible is solved by Systemd. The possibility of solving everything centrally contributes to the reliability and speed of the system. The positive side of Systemd is that it helps and has contributed to the spread of Linux. In fact, only two components are needed to assemble the working system: Systemd and Package Manager. However, Systemd is not mandatory, there are dozens of alternatives for those who do not like it.
egorf@reddit
> everything that is possible is solved by Systemd
Like an ability to run things periodically. This definitely has not been solved for decades prior to systemd, right?
egorf@reddit
> The fact that someone hates Systemd is a meaningless campaign
So, systemd is perfect and there is nothing to hate in it, right?
egorf@reddit
> In fact, only two components are needed to assemble the working system: Systemd and Package Manager.
Neither is needed. A perfectly working system can and often is built without those.
natermer@reddit
The primary real reason is because people were very proud of their tribal Unix knowledge.
Details about PID tracking, custom scripts, double forking and releasing file descriptors, distro-specific magical shell functions, all sorts of esoteric bash-isms and similar things that built up over the many decades of Unix init scripts.
All these things they knew that they could lord over other people and make them feel as if their sysadmin-ism was something elite. They could then go on forums and talk about how easy and simple it is if people would just take the time to skim through historical Unix documentation and examples.
Systemd got rid of that and made it "easy". Got rid of distro specifics, made double forking a liability, eliminated the need to worry about stdout and stderr, etc etc etc. And put all previously exclusive tribal knowledge into a blob of C code.
egorf@reddit
How come that nobody prior to systemd came to save us from decades of tribal Unix knowledge?
mzalewski@reddit
Because they refuse to get on with times.
systemd ship has sailed a decade ago. Hating it right now is silly, it is a de facto standard. If you work anywhere near Linux, you need at least basic familiarity with that tool. There’s nothing to talk about.
egorf@reddit
So, cron did its job perfectly fine for many decades and then all of a sudden systemd is the only right way to do this and people who complain refuse to get on with times?
Okay, irony aside, I do understand this argument and I think it's valid in general.
Having said that. Could it theoretically be that they hate it because of valid reasons?
void4@reddit
I'm using openrc-based distribution nowadays, and I don't feel I'm missing anything from systemd at all. OpenRC got like 10 times less code than systemd...
Besides, I've been asking for years what's the reason for systemd to use dbus, when you can implement much more simple and reliable IPC by just sending json to socket, only to be downvoted by respectable linux experts from this sub (who couldn't explain what exactly they disagree with). Then I see such news. Pathetic.
cyphar@reddit
I mean, declarative definitions of system services is a huge benefit of systemd over openrc. Maybe you don't need to deal with this often and so you don't think it's a big deal, but from a "building a distribution and maintaining many service scripts" perspective not having bug-riddled shell scripts for managing system services is a huge benefit. This is one of the reasons the Debian-based distros switched from Upstart.
As someone who does a fair amount of packaging, moving back to shell-script-based init configuration would be awful. Writing init scripts in a way that failures wouldn't break the state and that all of the operations were properly idempotent for complicated daemons was a nightmare and regularly caused bugs on Upstart-based systems for years.
egorf@reddit
> As someone who does a fair amount of packaging, moving back to shell-script-based init configuration would be
... a bliss. I vastly prefer a clean and clear init script over systemd's mess. sysv-init and others gave me transparency and control. Systemd took it all away. Good luck figuring why something works not or launches while being disabled and masked or does not launch while being enabled, etc.
And yes, you could easily, very easily end up with a convoluted unmanageable bash script and some maintainers did just that. But that's an option, not a requirement.
pigeon768@reddit
Did you mean to say "over sysvinit" or "over Upstart"? OpenRC has had declarative definitions of system services...for like...forever.
Here is the init script for sys-process/cronie, the cron daemon I happen to use:
This is not a new development, either. cronie is a fork of vixie-cron. vixie-cron's init script was updated from the upstream shell-script based init to OpenRC's declarative syntax in 2011: https://gitweb-cdn-origin.gentoo.org/archive/repo/gentoo-2.git/commit/sys-process/vixie-cron/files/vixie-cron.rc7?id=eb802c5c36cb634ea16ae3d967be93c97fd277c0 You'll see it's basically the same file. At that time in 2011, the only distro that used systemd was Fedora. Arch would make the switch late in 2012.
I can't find a blog post or changelog talking about an OpenRC changelog announcing the introduction of the declarative syntax. Gentoo supported sysvinit for a long time so it was was relatively rare to find the declarative style OpenRC init script actually used. (these days basically all the init scripts use the correct syntax) That vixie-cron init script is the earliest I could find on the web interface, and for some reason I am unable to download it locally to do a local search. I believe the declarative syntax is many years older than that and does in fact predate the systemd project by several years.
That was a day-0 feature of OpenRC. It was kind of the point of the project.
sparky8251@reddit
The amount of work Id have to do at my day job to keep traditional init scripts bug free as everyone demands more and more custom crap with custom behavior to run as a service... So glad systemd exists.
Business_Reindeer910@reddit
yeah it's gonna be way easier going FROM systemd to whatever is next (if there is something next) than TO systemd due to these declarative services. It really shows how few people actually understand this issue but somehow have very very firm opinions on init systems.
Mark_B97@reddit
Well 10 times less code... unless you're actually helping developing or changing the code for some reason that's not enough reason to choose one over the other. I haven't used openrc yet but from my point of view systemd works fine and in my experience it never caused any trouble
Pay08@reddit
I'm not an openrc developer but it's simplicity has helped me make bug reports in the past very quickly. Whereas I don't think I would have bothered at all with systemd. Also, last time I checked, systemd didn't have proper user services.
starlevel01@reddit
given that I just spent the last day porting my startup environment to use user services instead of my autostart file, I'm very interested to know what I actually did instead
cyphar@reddit
Systemd absolutely has user services and has for years. Unless "proper" means something very specific.
void4@reddit
10 times less code means 10 times less opportunities to get CVE. Also, I'm a software developer with many contributions to many different projects.
So yes, if I will have a desire and a free time to implement some feature in openrc then I'll do exactly that. And in case of systemd, I don't want to deal with corporate bs like this one. This is effectively not free software, to begin with.
cyphar@reddit
You linked to a non-systemd project where the maintainers said that due to US sanctions they cannot accept contributions from certain entities. Aside from it not being clear what this has to do with systemd, corporations are not the only entities that live in countries that have laws. If you would like to change the situation, call your local representative. There's nothing any open source project can do about the situation. The alternative is that the open source project maintainers get prosecuted into oblivion and get possible jail time for evading sanctions.
Also, free software has never meant that you are free to get your patches merged. In the early days, GNU didn't even accept patches at all and even today you can only get patches into GNU projects if you sign a copyright assignment so that they have the right to sue other people for copyright infringement.
void4@reddit
Friendly advise, don't talk if you don't know what you're talking about
If these guys are living in such a totalitarian states then, it's them who should do something, anything about that lol
derangedtranssexual@reddit
Wish you’d take your own advice
cyphar@reddit
I agree, the US and most of Europe is a totalitarian state. They should move to the only large country without Russian sanctions -- Russia! /s
MrElendig@reddit
Varlink has limitations and is not going to replace most use of dbus in systemd, I hope you actually watched the whole presentation instead of just reading the photonix headline.
wanzeo@reddit
I daily drive a postmarketos(alpine) arm laptop which is openrc… the first few days I was super into the simplicity compared to systemd.
But between my house and work I have probably 10 other systems that use systemd. It’s become a huge pain to live with both simultaneously and I really wish I could just go 100% systemd.
I’m smart enough to know when I’m not smart enough know, and if something is good enough for Debian stable, it’s good enough for me.
ElvishJerricco@reddit
Bear in mind that the systemd repo is far more components than just init. And pretty much every component is independent and optional. So it's probably misleading to say it has so much more code.
As for dbus, that seems like a nitpick nowadays given that varlink has been the new thing systemd has been moving to for many years now.
maokaby@reddit
Systemd is huge and hard to understand for non-professional enthusiasts. You can learn something like runit in 10 minutes, in case of systemd you can't be sure you understand it even after weeks of using it. So many people believe if something can be simple (and do its job fine) - it should be simple.
CondiMesmer@reddit
If you're comparing runit, which is just an init scheme, then it makes sense to compare it with systemd's init scheme. Systemd is a huge family of services, just like how GNU is a huge family of tools.
This is an example of a systemd service file:
I'd hope it doesn't take you weeks to learn this syntax.
egorf@reddit
> I'd hope it doesn't take you weeks to learn this syntax.
It's a deception. Obviously this syntax is simple, but once you give into it it won't be long until you start pulling your hair out and question your sanity trying to figure out for hours why sshd is listening on port 22 while a different port is explicitly specified in the config. And so on. Systemd is incomprehensible in practice. I bet at this point there isn't a single person on earth who knows all of it's commands and options, and I'm talking about PID1 only.
tonibaldwin1@reddit
That’s exactly why I am not fond of Systemd. I much prefer Dinit now (Chimera Linux) or even BSD’s rc(8).
tonibaldwin1@reddit
Why am I getting downvoted? I’m genuinely interested in an answer
CondiMesmer@reddit
then just don't install those parts lol
tonibaldwin1@reddit
Way ahead of you bro I’m already doing it
kernpanic@reddit
But.... it used to be....
Service nginx start Backspace backspace tus enter.
Now it's: Systemctl start nginx Systemctl status nginx
Some people struggle with change.
dagbrown@reddit
May as well use the features of your shell to save typing.
^art^atusif you're feeling like a smartass, or if you're being charged by the keypress or something.dmknght@reddit
It's much better than writing a huge arse shell script to make system's init.
Kwpolska@reddit
Debian and friends ship a script that mimics the backwards
servicecommand.laznp@reddit
wow.. thanks for the tricks... i need this
maokaby@reddit
It took me few hours to understand why putting a file into /etc/systemd/system makes it disappear. Like /etc/systemd/system is a black hole, it consumes everything. Then I found some ancient forum post explaining that this folder contents is controlled by system, and you should not put anything there or edit anything there. Probably its obvious for professionals, but not for me.
ropid@reddit
This doesn't sound like a systemd thing, it's the weird distro you tried. The files in /etc are yours, you are supposed to be able to customize them there. That weird distro would have done the same if it used something else than systemd.
maokaby@reddit
Mentioned behavior is easily reproduced in freshly installed debian 12, for example. I would not say its weird distro... Most likely its about specific systemd changes between releases. Honestly I didn't read all changelogs in all distros I tried... I just needed to install my own deb / rpm package, to ensure its working. And it did not, because I didn't understand systemd documentation good enough. It's mentioned somewhere there.
Now I put files into /lib/systemd/system instead, and its working as it should.
ropid@reddit
This sounds super strange. You are supposed to put your own service files in /etc/systemd/system and they are supposed to survive updates and upgrades and override the files owned by the system in /usr. It should be the other way around: if you modify things in /usr/lib/systemd/system, those files can be removed and replaced by the package manager.
This is pretty clearly documented in the systemd man-pages like
man systemd.unit. I just tried looking it up to make extra sure. There's a table in there somewhere that says this:With "the administrator" they mean you.
maokaby@reddit
Well, I thought so too. In fedora it works just like that. In debian you put files /lib/systemd/system , and it creates symlinks to /etc/ ...
Maybe I am wrong, it's just weird behavior I encountered, and didn't manage to understand (but found a work-around). As I said, it's overly complicated for non-professionals.
nroach44@reddit
That's very weird - I've only ever used debian since 9 and I've never seen that happen. I've got plenty of custom things in /etc/systemd/system.
ultrasquid9@reddit
SystemD does a lot of stuff that it really shouldn't. Its a pretty good init system (I started using Linux in the post-SystemD era, but I've heard that that space was a mess previously) but does it really need to be a bootloader, network manager, and login system too?
egorf@reddit
> post-SystemD era, but I've heard that that space was a mess previously
It wasn't. It *could* be a mess, because initscripts were just that - scripts. So some people chose to wtf in bash up to a point where initscripts became unmanageable.
Other people, me included, had clean and clear initscripts with zero feature creep and hence a controllable, sane system boot.
I like systemd as PID1 though. Everything else is just cancer.
Leliana403@reddit
Nope, a you'll be pleased to know it isn't. Those things are separate, optional programs. 🙂
__konrad@reddit
My list is short:
Leliana403@reddit
What do you mean? Of course it does. It doesn't stop them unless you pass
--nowbut it absolutely does disable them (for next boot).egorf@reddit
> Of course it does.
Of course it doesn't. It absolutely doesn't. This is why `mask` was invented.
Wait for it, they will find a way to overwrite even that, so perhaps "really-disable" will come up at some point.
__konrad@reddit
For example, "disabled" systemd-oomd starts again after reboot, so it need additional "systemctl mask systemd-oomd"
Leliana403@reddit
Weird. When a default-enabled service is disabled, a symlink is created from
/dev/nullto the relevant filename in/etc/systemdso it should fully override the vendor service. 🤔venquessa@reddit
In many instances of modern distros it can complicate things unnecessarily. When things go wrong and you go looking in the "usual" places you find # AUTOGENERATED DO NOT EDIT HERE #
Now you have to go and find out how this particular distro was setup regards things like "resolv.conf", "hosts" and all the other, now dynamic config files systemd assimilates. Often it requires a process of finding the template, editing it or it's config and then updating it in systemd. The first time is hell.
Part of that is "old timers dont like change", part of it is not having encountered many of these errors on systemd systems before.
I think for "bare bones" base systems, modern distros do go too far. A lot of the "bells and whistles" of systemd are unnecessary on the likes of servers versus desktops with dynamic hardware et. al.
egorf@reddit
systemd-resolved is easily the worst offender. Absolutely evil piece of crap.
Fortunately, for now it's easy to remove. For now.
SeriousPlankton2000@reddit
For me it's
1) the Pöttering attitude. "If it doesn't work, it's because you are dumb!" You are using a stupid if distribution if there is a problem, you should uste thisandthat instead " (I'm already using thisandthat)
2) They try to force everybody to replace something that works wit something that works their way (if it works)
3) If it doesn't work, it's "sucks to be you, your use case isn't supported"
4) It's much easier to just have a shell script, test it, see that it starts your daemon correctly and make a symlink to start it.
5) On my system, systemd developed a problem that it didn't recognize the system partition being mounted after it did mount it, I asked the devs about it and there never was a solution. First it was enough to remount,rw the partition and continue, but then it got worse and I had to re-install that system. TL;DR: Systemd is too complicated for the devs to know what it does.
TL;DR: They beak things and feel that others are responsible to fix it / wok around it.
markusro@reddit
As you can see plenty in this thread, so sad. And then people wonder why others become defensive.
Also a lot of "99% bearded Rednecks". Just dismissing 30-40 years of experience is not good idea. Yes, old people do not like change, but change for changes sake is not a solution either.
egorf@reddit
> dismissing 30-40 years of experience is not good idea
It's an excellent idea shared by the vast majority of younger sysadmins. It's new therefore it's better.
ferric021@reddit
I'll run the risk of over simplifying by saying that it does not "do one thing and do it well."
ElvishJerricco@reddit
I do think this is a pretty common argument and I think there's a fairly simple rebuttal. Systemd isn't one thing doing too many things. It's many things each doing one thing well. Systemd is comprised of many components, and for the most part only PID 1, udev, and dbus are mandatory. The networking tools, the system management tools, the boot loader tools, the TPM2 tools, the file system tools, the user management tools, etc. etc. are all separate. Each of them does its domain of responsibilities and does it well. In many distros (like NixOS), most or all of these things are optional, even if encouraged. The idea that it's bloated because all these components are in the same repo rings hollow to me, because other than the fact that they all share the same philosophies, they are fairly independent.
egorf@reddit
dbus is not mandatory on Ubuntu server. I remove the whole list of dbus packages on freshly installed servers and everything works as usual with no problems whatsoever. Of course this won't do on desktops and of course things may and probably will break in the future. But for now it is possible.
ferric021@reddit
Regardless of how many pieces build it up, by using it you're buying into an entire ecosystem that is more than just system startup but is also crontab and logging, etc.
Choosing systemd is more akin to choosing between Qt and Gnome, where generally if you install one you use that one's ecosystem and not the other.
edgmnt_net@reddit
In that sense it's not very different from coreutils. And even bash is coupled to that.
RangerNS@reddit
That is about scale, isn't it?
Programmers are taught to write modular code, break things down in to methods/procedures/subroutines/functions that do "one thing and do it well". But this does not lead to compiling 10 line functions, and wrapping them together with UNIX pipes. This means producing some larger construct, whatever it might be called in the language/paradigm of choice, module or class or something,. And the class does "one thing". But nobody is compiling classes and wiring them together with pipes.
systemd is made up of a lot of 10 line functions that "do one thing well", bundled into modules and libraries, each that "does one thing well", and compiled into several binary files that each "does one thing well". And collectively, the entire project, provides "a system and service manager", and does that well.
Or not well, and you can argue particular points.
But it is one thing.
Now, that one thing had a dramatically increased scope than the one thing that traditional
initsystems have had. And you know what? the SysV and BSD versions ofinithad very different ideas of what and how to do "one thing", even historically.True, the scope of the "one thing" that the systemd project handles has increased, this scope has not increased meaningfully in years. It has found a meaningful sense of "one thing", and is "doing it well".
egorf@reddit
> But it is one thing.
Absolutely. Booting the system, syncing time, watching file for changes, resolving domains, running binaries as root, appending log files, etc, etc - all of these is totally one thing.
ferric021@reddit
I am not the final arbiter of what "one thing" means in language, but if "one thing" means "one entire ecosystem of how to start services on boot, manage logins, schedule discrete jobs, resolve dns, et al" then I guess you do you.
linuxhiker@reddit
This but also...
Cause people hate change and are generally just whiners
za72@reddit
what problem does it address?
egorf@reddit
I don't know why are you downvoted. It's a legit question if we're not just talking solely about systemd as PID1.
yiliu@reddit
Tons and tons, honestly.
Should this all be done by one piece of software? Well, there's the rub. On the one hand, there's what the corporate types call synergy been the different responsibilities (for example: a single config format for all these tasks instead of cron, inetd, and sudo configs, as well as pages of arbitrary bash code). OTOH, that means a big hairy mess of code with a significant attack surface.
I think now that it's matured a bit, it'd be really hard to give up. And in the meantime the 'other' side hasn't produced anything (like, a family of standalone tools) that could begin to provide the functionality of systemd.
WjU1fcN8@reddit
Systemd are many small tools in a single repository.
People talk talk badly about it just don't know what they're talking about.
yiliu@reddit
Well, yes and no. My understanding is that it's a bunch of front-end tools (each with a specific purpose, relatively unix-y) but they all interact with the same running init daemon. When people say systemd is bloated, they're talking about the init daemon.
The old SysV init literally just started up and launched a separate script, and it was that script which actually performed startup, launching scripts in
/etc/init.dor whatever. The init job kept running, but it had almost no responsibilities, just killing procs on command or whatever. You could change the script that was called. I remember people doing crazy things, like replacing their whole startup system with a Makefile in order to speed up startup.Not so with systemd. In order to support fancy stuff like system events, cron-style timed scripts, interdependencies between jobs, etc, the daemon running during init does a lot more than just triggering a startup script. You gain a ton of functionality by doing that: stuff that was really difficult before ("if this job restarts, also restart that job", or "run this script before that job starts up", or "leave a socket open and launch a new daemon in an isolated namespace each time there's a connection") becomes trivial. OTOH, there is a lot of extra complexity and potential attack surface where before you had a dead simple daemon containing a few hundred lines of code.
WjU1fcN8@reddit
Systemd's PID 1 does one job and does it well. It manages daemons.
Well, actually, it also does resource accounting and MAC, but that's inherent to doing the managing job well.
Thinking that one of the worst messes ever, init scripts, is somehow something to defend is concerning.
Even people that actually have valid criticism of Systemd think there should be daemons that do the same thing. The only thing is that they think it shouldn't be PID 1. PID 1 would launch management daemons that do the same thing as Systemd's PID 1 does. Only they think that they should be able to run more than one of them and not have this be a redundant layer. (If one doesn't care about it being redundant, this works fine).
The problem is that resource management and mandatory access control must be centralized. The Linux kernel had a cooperative model in the past and it didn't work. Now the kernel mandates that only a single daemon has control over the resource management trees.
The alternative model then would require a different daemon that does resource control, and the managing daemons would need to closely coordinate with the resource server. This integration is so close that thee would need to be coordinated releases.
Although this could technically be done, bugs fester at interfaces.
Having this all be centralized makes a lot of sense. Specially because then the managing daemon can make use of the spacial characteristics of PID1, which would be lost in the alternative model.
yiliu@reddit
I'm not arguing against systemd. I'm just saying it was indeed a change from the SysV status quo. People who were used to SysV, and in particular those who had simple server setups (launch once, run forever) with which they were intimately familiar, were upset.
Systemd is great for a laptop which regularly switches networks, adds and removes devices, hibernates, etc. It could be seen as massive overkill on a server. Honestly, though, I really appreciate the extra security it allows without much additional complexity, and I think newer sysadmins will appreciate that.
All of which is to say: I basically agree with you. But I do see the other side.
ferric021@reddit
I think this is the best kind of take on systemd. It provides an ecosystem that ties previously disparate things together, but it does that deliberately to solve real problems.
I think this is much more compelling than the "no its not doing more than one thing well" arguments.
nroach44@reddit
What's a nice way to list all services that failed with sysvinit?
With systemd it's
systemctl list-units --failed.As a paid sysadmin, it's so fucking nice to get one command that's "tell me what's wrong".
za72@reddit
I'm glad you mentioned your a professional sysadmin... so the entire linux operating system has many many system tools that provide system diagnosis and status... somehow we managed to operate multi data center linux instances...
Those who do not understand Unix are condemned to reinvent it.
Most processes store their . pid file in the /var/run directory or the /var/run/ directory.
checking there will give you hints as to what's running.. if your dealing with any stale pid files, etc etc...
when system tools try to be clever and do multiple tasks and pretty print with colors it introduces another layer that could be a potential fail point...
it's pretty... but why add another utility to further complicate admin-ing with different OS flavors and versions...
I like how I got downvoted for simply asking to justify it's use... for years and years daemons came with pretty standard init tools... it's so simple and extensible...now your daemon has to support two flavors of system status and control scripts... why?
Leliana403@reddit
This is hilarious.
za72@reddit
all I see is upset admins worshipping an over ambitious overblown admin tool
Leliana403@reddit
Tell us you've never touched a Linux system professionally without actually saying it.
za72@reddit
brother I've ran multimillion datacenters under solaris/*BSD/linux + cisco doing cc transactions withe the big 3 CC giants... worked and got a patent that paypal/amazon/target had to work around... I could fucking care less about impressing you...
mop the jizz on your way out
Leliana403@reddit
Sure you have. 🙃
nroach44@reddit
I have hundreds of servers "under my support" across tens of clients. Some of these are Debian, Ubuntu, RedHat (6+), CentOS, AWS Linux, Alpine, and Solaris (8+).
The are running on Azure / Hyper-V, vmware, KVM, or bare metal.
Some are just running normal OS services, some are running custom java / python / etc.. apps.
What I need to know when patching, or working an incident, is a very quick "status check" of the server.
systemctl list-units --failedis a very quick way to get "what's wrong". If a service has failed because of a bug (e.g.snmpdcrashing because of transient network interfaces (thanks docker)), it'll showsnmpd.service FAILED.If
kexecfailed to start because some idiot installed it but didn't configure it, it'll show that as failed.If the NFS server failed because a filesystem is missing, it'll show as failed.
snmpdhas a PID and a socket. The kexec crash kernel scripts and the NFS server scripts (just a wrapper aroundexportfs) sure as fuck don't.Solaris has this - it's
svcs. sysvinit does not have a direct equivalent - it's just going to call each script withstatus, and last I checked half the initscripts in RHEL6 didn't implement that. Windows NT has had since at least 2000.What kind of "service manager" can't tell me what services aren't running?
This point always boggled me - have you seen the kernel's source code lately? It's multiple gigabytes of source code and it's not just an OS kernel, it's hardware drivers, network protocols, filesystems et al. That's not "do one thing"...?
systemdis packaged as multiple things, but other than the core "init" and "journald" (which let's be honest, probably should belong together), you can disable or remove the rest.za72@reddit
please put your epeen away... I surrender, you've managed to convince me - I've been a fool for so long... but now I see... will you be splitting atoms in the back kitchen?!
RangerNS@reddit
I would prefer to actually know.
It absolutely is. And a pidfile existing tells you nothing about its process working, if there is some internal failure. Systemd seeing a collection of processes in a cgroup running also tells you nothing about some internal failure.
Now, if the process(es) isn't running, and you can detect that locally, then one really might want to respond automatically and locally. Historically, none of the
inittool chains provided for this, and no Linux distribution integrated any of the low-level daemon monitoring tools into their init stacks. You acknologe there is a problem to solve, simply listing off a bunch of tools that solve the problem only 10% of the way isn't a response. All of the various add on "supervisor" tools were never tightly integrated into either any distribution, or embraced by more than one particular application. All of those options were imperfect. systemd with cgroups is better, but still you don't know if the process is actually working. systemd solves the "process running?" problem 100%, but that doesn't address the "process working?" problem.Absolutely. Do remote monitoring. systemd doesn't take from that.
But none of those. They don't help at all.
za72@reddit
ok you win you've convinced me... this is the stupidest holy war
linuxhiker@reddit
A decade ago I was speaking at a user group and they asked me the same question.
I said it offers proper error handling and quicker boot times.
They said, I don't want quicker boot times.
The world moves on whether you want it to or not.
DheeradjS@reddit
If boot time is an issue you honestly have other problems.
That said; the fact I can configure a good deal of the system with the same syntax makes it so much better than dealing with "One thing only" applications.
Asleep-Specific-1399@reddit
So the general methodology of Linux was everything is a file and every executable only does 1 thing.
Systemmd breaks this and it works more like a service similar to how windows services works.
This addresses a few things that run init.d had problems with like getting quick statuses , pid handling, etc..
The reason why people attempt to avoid is usually for 3 reasons.
It's steers from pureness of Linux original design.
Due to how it works it requires about 2-3 steps more to configure when compared to init.d.
Due to the popularity of systemmd exploits are written for this method of starting a service and a quick method to be immune to it, is to run anything but systemmd.
I personally don't run it, not because I don't like it, but I happen to be using Gentoo and rc works fine.
Business_Reindeer910@reddit
calling the "linux original design" pure is wow. Linux distros have always been a mismatch of random stuff together, even with sysvinit.
The BSDs are much closer to "pure".
Asleep-Specific-1399@reddit
Ya, I personally don't have a dog in the fight. I do find the mismatch file hierarchy annoying.
Having to relearn simple stuff is never super fun, specially when it's always at 2 am when your actually trying to just close something.
I personally would prefer a single direction, but that's impossible at this point, and I already know the quirks of most of the popular distro.
Business_Reindeer910@reddit
systemd is what is helping provide that single direction.
intelminer@reddit
No. That was UNIX. Linux is a clone of UNIX
What? What does this even mean? Windows services work in a completely different way to Linux/Unix daemons, because it's a completely different operating system
You mean
sysvinit. systemd isn't even the first attempt to fixPID1either. We've had Upstart, OpenRC, runit, BusyBox and othersWhat "pureness"? Linux is just a kernel. That kernel is monolithic even. By its very nature it does not "do one thing and do it well"
Have you ever written a sysvinit script? This is so incredibly false it borders on comical, frankly
Since you've repeatedly typed it out as "systemmd" it's worth clarifying it's systemd. But anyway
What "exploits" were written that target, presumably,
systemctl? CVE-2023-26604 exists but requires running systemctl commands with an improperly configured sudoers fileAs someone who helped prod along systemd to parity in Gentoo over a decade ago, OpenRC (rc.d is something else!) was miserable and I'm quite glad that Gentoo provides the choice to use either in equal measure for the user
Asleep-Specific-1399@reddit
I think your way more qualified to answer the question op has.
I just highly summarized the entire thing, I don't actually care what type of method is used, was my point.
The question is a opinion piece on why some people run something besides systemd.
The entire point of the post was to give a high level overview why people don't generally want to run systemd.
I am typing on a phone so auto correct tends to do w/e, it is not particularly convenient, again I believe you should answer op's questions.
kinda_guilty@reddit
sparky8251@reddit
And different subsystems. Man is it nice to be able to configure services, "crons", mount points, "containers", networking, DNS resolution, NTP, and more all in the same place with the same syntax across so many functionally different systems.
ferric021@reddit
Agreed. Its a lot easier to bitch and moan than it is to build an ecosystem of tools that fix the problem.
A_for_Anonymous@reddit
It meets neither.
aqjo@reddit
Like Emacs.
ferric021@reddit
A great example of something that many people also hate for breaking that same rule.
CondiMesmer@reddit
how so? it's many different programs
ferric021@reddit
systemd is an entire ecosystem. Buying into systemd for system startup is buying into a logging and crontab and many other components.
sidusnare@reddit
exactly.
xplosm@reddit
So? Neither does X11, neither does Wayland and neither does Emacs. Just to name a few.
ferric021@reddit
These are great examples of the few exceptions, I don't believe they are poster children for all solutions to follow though. One of the reasons I don't use emacs is because it doesn't do just one thing well, that's actually a fairly common reason why a LOT of people don't use emacs.
The existence of some exceptions today do not on their own provide any compelling reason to make the same exception in all other facets of the system.
ThatOneShotBruh@reddit
And neither does the kernel itself 🙃
Dramatic_Object_1899@reddit
The only commands which do are YES and CAT.
cyphar@reddit
Did you forget about
cat -v? Nothing is free from bloat.Dramatic_Object_1899@reddit
I did. Can you imagine the monstrous one-liners we’d use if each command really did one thing?
johncate73@reddit
It's a jack of all trades and master of none. That is the way I have always put it when it comes to systemd.
edgmnt_net@reddit
Yet systemd does daemon lifecycle management much better and more reliably than init scripts and self-daemonizing stuff. That's been a mess in many init systems.
MrElendig@reddit
This argument is just dumb though. And if you were to follow it then you eould.have to sop using gnu/linux at all.
brnme@reddit
Expanding on this rather than being simple an init system (like initd) it also adds in a bunch of extras. Top of mind network manager, resolved, journaling. There are more i am sure from someone with more knowledge. This is what i have picked up on the topic from dedicated nixers. I personally like the added utility it provides some people prefer the old service system and initd. Just my 2cents
HelicopterUpbeat5199@reddit
I was happily using rc init script when systemd came along. It felt like someone was trying to make linux more like windows, which wasn't my favorite thing. Every few years I wite a startup script, whatever they're called, for systemd and I always wish I could write an old rc script instead. They do have some nifty features, and systemd does boot faster on multi-core systems, so it's not all bad.
egorf@reddit
While systemd as PID1 is a nice thing, I would go back to upstart in a heartbeat. Things were so much more easy, comprehendible and under control with init scripts. Now you can't tell for certain why a certain service launched and where its configuration is actually stored. Some services is close to impossible to remove/disable, they keep relaunching and you have to actually learn systemd to figure out why and sometimes even that is not enough.
Absolutely fuck systemd.
Sentreen@reddit
Really? I had the opposite experience. I run openRC on my server and systemd on my laptop and writing a new service for systemd is just trivial compared to writing a service script. I still have to occasionally
zapsome of the services I wrote on openRC while that's just not an issue with systemd.If you're very familiar with shell scripts I can see how you can be faster writing a script, as you do need to go through the docs to find the right option to tweak for systemd, but I found the docs to be quite good and easy to search.
HelicopterUpbeat5199@reddit
You make an excellent point! If I didn't know how to write shell scripts or systemd services, I'd probably find systemd easier to pick up.
faxattack@reddit
More like MacOS thought
FunAware5871@reddit
Imho the main issue with systemd is how it tries to solve an actual *nix issue (init is a mess and sometimes hard to maintain/debug) in the worst way possible (a single explorer.exe hydra).
Services, watchers and timers are actually great, but then it wants to handle tasks like encryption, partitions management, and so forth all the way up to user space... With a real high risk of becoming the bottleneck (see: X11) and a vulnerabilities injector (see what happened with ssh) as it becomes more and more complex.
Yes, systemd is modular by design and parts of it can be replaced... With other modules designed to work with systemd. Give it a few decades and it won't be far for what X11 is today. See how easy, straightforward and painless moving away from X11 has been? Now picture how moving away from a "I do everything!" system component will be...
I'm ready to admit I was wrong if that won't happen (and I'll use systemd in the meanwhile, as it's much more convenient than other init systems right now), but the more I look at it the less future proof it looks...
sqlphilosopher@reddit
Systemd is a modular suite of software. One of them is the init system. Why do people get this simple fact so wrong?
egorf@reddit
> Systemd is a modular suite of software
Technically yes. Practically not even close.
FunAware5871@reddit
Systemd is modular as in you can replace single modules with other ones that perform similar tasks... And the result is they all depend on the systemd ecosystem to work, sometimes to the point it's impossible to use those components as stabdalones without bringing in unnecessary overhead or dependencies.
So yes, systemd is a single hydra (entry point which manages everything) with coundless heads (all the modules it manages), to the point it can even inject vulnerabilities into them (again: see the recent ssh incident).
The moment the core of the suite becomes obsolete or the need for an alternative arises, all the modules will be affected and they will all need to be migrated at the same time. Like a huge, single, overreaching piece of software.
It's not really hard to understand: a single suite handling all these tasks will stifle innovation and development as soon as its technical limits are reached... And by then, it'll be a colossal task to migrate away from it, while a good chunk of user will resist change. We've already seen all of that with X11 and wayland, and this will have a much bigger impact as systemd is trying to take care of the majority of the OS's main tasks.
Leliana403@reddit
Because if they acknowledge they are wrong or were misled on this point, they might start questioning other things they were told and that's just unacceptable. Much easier to just keep repeating the lie in the hope that one day, it might magically be true.
EverythingsBroken82@reddit
because it's not easy switching to other modules. in my opinion, because the interfaces are not clearly documented.
Like where does init and systemd-networkd interact and how. writing a dropin replacement seems complicated. And people rail at you when you say you want to do it for whatever reason
edgmnt_net@reddit
It probably cannot really work well any other way. You also need rich APIs to provide a sensible notion of permissions, like in Android versus trying to get similar control through DACs and MACs. You can't just wish that complexity and coupling away, at least not at all levels.
FunAware5871@reddit
But we're not talking about APIs or protocols here: systemd has become a hard dependency for everything, and that's just wrong.
It isn't that bad as an init system... But stuff like logind, homed, timesyncd? They can't really be decoupled by systemd, and any alternative module must be made specifically to work with systemd. What's worse, we even have user space software depending on it to work (looking at you, gnome).
I'd be fine with a standard protocol to use (let's say the way wayland works), but having a single extremely complex, expensive to maintain/fork and hard to move on from piece of software that wants to manage everything, from init to user space? I fail to see a scenario where that brings more pros than cons in the long run, especially should systemd ever become sub optimal or obsolete. Good luck migrating away from that...
sparky8251@reddit
I've... I've literally uninstalled these and installed the alternatives on systemd systems and never had an issue? Same for systemd-resolved, systemd-networkd, and so on... None of its required, you just have to learn how to configure the alternative yourself since the distro doesnt default to it?
Leliana403@reddit
Why are you lying? None of these are required to use systemd. In fact, the only parts of the systemd suite that aren't optional are systemd (PID1), journald and udev.
Not true at all.
No, we don't. These things depend on systemd APIs, which is very different from depending on systemd. systemd APIs can be and are provided by anyone willing to do the work, such as, yno, elogind.
It's funny how you think the world will end if we try migrating away from declarative config files but apparently have no issue with the migration from a massive nest of shell scripts each with their own distro specific features and methods for handling basic things like PID tracking and logging.
FunAware5871@reddit
So... You linked elogind... Which is a way to use logind outside of systemd... Which only proves you can't use logind (a systemd module) outside of systemd without all of that extra work.
And, on the very page you linked, is stated it's "designed for users who prefer a non-systemd init system, but still want to use popular software such as KDE or GNOME that otherwise hard-depends on systemd"...
Thanks for proving my point, I guess?
Leliana403@reddit
"elogind is the systemd project's logind, extracted to a standalone package."
It's literally the systemd module. Outside of systemd.
Also, make up your mind. First it's "you can't use logind outside of systemd" then it's "ok elogind is a way to run logind outside of systemd" and then back to "this proves you can't run logind outside of systemd". I'm not entirely sure how being able to run logind outside of systemd is actually proof that you can't run logind outside of systemd but whatever.
Obviously a minor mistake by the editor then given that GNOME and KDE do in fact run perfectly well on non-systemd systems which is easily provable by the fact that Gentoo exists and runs both perfectly fine without systemd because they depend on systemd APIs, not systemd. I know you really don't want this to be true but it is, so get over it.
stroke_999@reddit
I don't know why you comment has so low likes. It is really correct. Systemd is doing the job that someone else did better, take for example timesyncd that is useless where there is chrony that works better, or as you say the encryption when there is luks that is fantastic. The problem with systemd tools is that they require systemd. To port logind that is the standard now there was a lot of trouble and not all the things are addressed yet. It seems to me that systemd don't won't concurrents, and because of this it make things that only work with systemd. The worst part is that sometimes a project for example gnome, take systemd as a dependency and this is a disastrous thing. I personally use distro with musl (alpine Linux or void) and systemd as a dependency with glibc. It is not very portable, just immagine that the BSD world has prefeared to remain with the old school rc that is basically no init. So to recap: systemd is solving problems that don't exists in a worst way wasting programmers time, it is not portable so I can not use in my distro (and this is how I find that systemd is shit), and it is also buggy, difficult to understand and really take over the operating system, making all things harder not easyer, take for example the ulimit, in Linux you need to change /etc/security/limits.conf, in systemd every single service has its own limits.
sparky8251@reddit
Going to point out, one nice aspect of this is applications can signal to systemd what their limits should be on start. So now, instead of configs in 2 places for a service, the services config file itself can set limits of any amount. Haproxy does this if you want an example.
semi-@reddit
I thought limits.conf was applied through PAM, and thus only applied to processes that are started by users logging in somehow, not services started directly from PID1. Or is that just the common usage now in a systemd world?
In either case..Why wouldn't you want limits for your service defined with the service definition? How else do you ensure the limits apply to the entire service if the service forks multiple processes?
stroke_999@reddit
For security reasons services are started by a user, systemd want to make a more advanced implementation but you can't reproduce every aspect of a user, and if you do this with systemd than the users will be useless. However if you define limits for the entire system, services where limits are not specified will escape the configuration in limits.conf.
ferric021@reddit
This seems spot on. Choosing systemd is buying into an entire ecosystem. There's a reason someone is deliberately building the ecosystem, there are problems it is solving, but it IS an entire ecosystem.
KamiIsHate0@reddit
That is exactly my problem with it. Linux people love to boast they are not Windows people, but defend and love how systemd works. That hydra of dependencies will be a mess in 5-10 years when someone develop something different/better.
SlackBob@reddit
Part of it is probably due to its original author being a controversial figure. He had previously brought Pulseaudio which was also not easily accepted by everyone. Combine that with his communication style, systemd being big in scope and you have something that was easy to get opinionated about. They also had a few bugs early on that got attention which didn't help
A_for_Anonymous@reddit
A few bugs is a major undersratement. Poetterware is always monstruously complicated and opinionated, has a serious learning curve, it's extremely ublike anything UNIX, is pushed years before it's stable, it breaks everyone's system, and it brings a ton of CVEs.
NummyYum@reddit
Ugh early Pulseaudio gave me nightmares.
Saflex@reddit
Out of spite
AutoModerator@reddit
This submission has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
big_lv@reddit
My issue with systemd is that it feels like they're trying to emulate windows and the registry system. I liked the simplicity of each program being responsible for its own configuration in the /etc directory. Startup and run levels were as easy to configure as making a text file. I use systemd only because the distro I use converted to it several years ago. But it's like anything, it's their distro, and I'm just using it outside of an enterprise environment.
Leliana403@reddit
The registry is a key-value store. What does that have to do with an init system?
They still are. systemd doesn't touch other programs' configuration and its own configuration is entirely text files stored in
/etc/systemd. Why exactly do you think otherwise?They still are. They're just called targets now.
big_lv@reddit
When I try to control the programs, I get an error message that tells me the system is controlled by systemd, and I have to control it that way. Inside the rc.d directory structure is a readme that says to use systemd. I have enough experience to know that I could mess with it by hand if i dig far enough, but it could also mess up their stuff, so I do it the way they want. My ease of us is more important than being married to one way.
Leliana403@reddit
You get an error message because you're trying to use the deprecated command
servicewhich is just a wrapper aroundsystemctland the script is simply telling you thatserviceis a sysvinit command and you are not using a sysvinit system. That is all. It does not mean systemd has literally taken over your system, config files and all. It does not mean/etcno longer works. It's literally just saying "You should stop using this deprecated alias as it may be removed in future".big_lv@reddit
No, I'm not using service, I'm using the individual program's control mechanism. So inside the /etc directory, "./program.d reload" for example.
Every program that I tried had the same message.
Do what you want, it's fine. I decided they beat me into submission, and I'll comply since I still like the distro.
It's like when they put USB control into the kernel (not a module), so I could no longer restart it when it messed up, a full reboot is required. It's just the evolution of the os, and I can either be angry or adapt.
Leliana403@reddit
...which is exactly what
servicedoes behind the scenesBecause they're all going through the same wrapper.
rileyrgham@reddit
People have different opinions.. Some people don't like change. Some people prefer to advance or experiment. Done. The devil is in the details and if you were really interested you'd find the arguments in 2s on Google.
FamiliarMusic5760@reddit
I hated systemd in the beginning. Now, years later I can’t even begin to imagine how difficult life was before.
opensrcdev@reddit
I like systemd and snap packages.
gnomebodieshome@reddit
It threw a lot of wrenches in working systems to solve problems that didn’t apply or would merely be a nicety for 99.9% of Linux kernel based systems. It caused our company thousands of hours of debugging server stacks.
gellenburg@reddit
Because we didn't need it and it introduced a level of complexity into Linux that went against everything that Linux, Minix, and UNIX was based on.
The more complex a system is the more apt it is likely to fail.
SystemD was started because rc.d/ init "wasn't invented here".
It was an ego-boost and nothing more.
Leliana403@reddit
And there is nothing at all complex about multiple distro-specific shell scripts for the same service which all have to implement basic things like PID tracking and logging themselves, right?
Have you ever actually written an init script? I suspect not.
gellenburg@reddit
I do not use WordPress. At least not since Mullenweg destroyed the community and ecosystem.
l_exaeus@reddit
Oh my f God, again?
DoUKnowMyNamePlz@reddit
And I'll f***ing do it again!
sqlphilosopher@reddit
Because they confuse a modular suite of optional software, one of which is the init system, with a big monolith that violates UNIX philosophy. I.e, mostly ignorance.
cyclonewilliam@reddit
For better or worse systemd was imposed by enterprise onto desktop/server space. It has useful tools for high level admins but developers, older admins and desktop power users can find it a little onerous. New users over say, past 10 years often have no other point of reference so are fine and consider older users in the community to be complaining old men. I use systemd on all my systems because... it's there. It seems to many of us like the old xy problem taken to an extreme and given license over almost all of Linux.
I will say that with our own software, a common request I get from support is "how do we turn of db logging" and I work in a large enterprise space.
PMzyox@reddit
It’s mostly a campaign being perpetuated by agents of big sudo
AnotherMiggy@reddit
I laughed way to much at "big sudo". Thank you.
PMzyox@reddit
Haha same thing when I thought of it. Had to post lol
MemoryNotSignificant@reddit
systemd doesn't work with docker. It sucks because you have multiple ways to manage services. Also, they were some bugs in the way systemd captured stdout/stderr. I think they're resolved now. Sometimes, it failed to capture output in the journalctl log. The log just said the application existed with exit code blah bla bla. It woudn't show where it went wrong. If you run the application in console manually, you can see the error. May be buffering issues.
Leliana403@reddit
What are you talking about? I use docker on systemd systems all the time. I'm pretty sure that if the most popular init system and the most popular container management tool were incompatible, we'd have heard about it by now.
MemoryNotSignificant@reddit
systemd inside docker container
ar1fur@reddit
kerneld
krozarEQ@reddit
A lot of us old farts (myself since 1992, although not Linux until 1996) we often like the idea of a simple the-one-user-is-God system. But simple is in the eye of the beholder. For a large project, deploying OSes at scale, and maintaining a distro, the Systemd suite makes things easier with a unified service manager. I don't have a big opinion on it anymore. The traditional Unix philosophy started dying in the 1980s, and for good reason. That's the far extreme of one end of the spectrum. The other is pointless bloat purely for ease of development (i.e. Electron and other browser-engine frontends and frameworks). I feel SystemD fits somewhere in the middle and the middle is usually a good place to be.
Integrating it with C (sd-bus), Python (python-systemd), C++ (sdbus-cpp) or shell via runtime (systemctl) is mostly effortless.
Linux distros have become more homogenous since the earlier days and that's to be expected due to its success in the enterprise space.
stroke_999@reddit
Think of this, if systemd succeed in replacing all Linux instruments, all the better projects out there will be no more financed, and all the Linux will be in the hand of redhat.
Leliana403@reddit
Could you name some better projects that were funded and have now stopped being funded as a result of systemd existing?
ChapterWorried8899@reddit
who hating?? 🙂🙂
keremimo@reddit
I also hear things about how we shouldn’t use Systemd but you will find a neckbeard rejecting anything. Gimp, Ubuntu, Arch, Gentoo, KDE, Gnome, Hyprland… people will find a reason to say “Don’t use this, just do Linux from scratch, you’ll learn” when all you want to do is to have a system to browse websites.
I say use what works for you and don’t pay much attention to every opinion you hear out there. Everyone’s got one.
RunOrBike@reddit
The thing is that the change was so big, that it lead to the cancellation of alternatives. It effectively eliminated choice for the user.
keremimo@reddit
The same way how Linux itself eliminated other smaller alternatives when it came out? That’s life. It is useful. If it stops being useful an alternative will emerge.
RunOrBike@reddit
Except that Debian was always about choice and giving the user freedom. The kernel wasn’t, it was a hobby project by a techy.
Leliana403@reddit
Giving users freedom doesn't mean spending developer time on every single possible use case anyone might have. Debian doesn't stop you using sysv. It just doesn't do it for you.
Hikaru1024@reddit
My objections to systemd at this point are historical, largely technical problems that I now believe have already been solved years ago.
But, I am still not willing to switch to a system I had so much trouble with in the past - after all what I'm using now works, and works well.
In the future that might change, and I'll have to try it. At this point it might even work.
Degenerate76@reddit
The suckless site contains probably the most comprehensive collection of systemd critique:
https://suckless.org/sucks/systemd/
geeshta@reddit
Most actual users don't care it's just reddit snobs
No_Diver3540@reddit
I love to use systemd over every other alternative. Makes life and work so much easier.
throwaway490215@reddit
systemd solves the Red Hat problem of having to administrate a bunch of desktops.
I don't have the problem, so it doesn't solve anything for me that runit doesn't solve simpler with less moving parts.
Mars_Fox@reddit
why do you care about downvotes? Why are redditors such pus es…
Anyways, the simple answer is - Linux “enthusiasts” are very specific people and there’s a lot of philosophy and politics involved. One of the core principles is KISS (keep it simple, silly) and systemd goes way against that. It’s bloat. It’s good, but it’s still bloat and many people prefer to streamline their distros and keep them minimal, hence alternatives
jean_dudey@reddit
I do hate on it because it basically forces every project out there to assume a distribution uses systemd and breaks if it doesn't.
nicholas_hubbard@reddit
Systemd is fine and works well. However, I find both sysvinit and runit easier to understand and use as a means to learn about init systems in general. I also just don't like how popular it is and how it's taken over, and so I continue to only use distros that haven't adopted it.
Mars_Fox@reddit
bloat
JazzCompose@reddit
On Ubuntu 22.04 systemd works well with a custom security camera object recognition and alert app written in Python. The details are here:
https://github.com/audioclassify/CedarAlert
Marketfreshe@reddit
Low rent comment, sorry....I don't hate systemd 🤷
daemonpenguin@reddit
You could have just asked the people "hating" on your system. Or you could have typed your question into google. This question gets asked here weekly and, at this point, it is just trolling.
OpenSourcePenguin@reddit
Because it's cool to do so.
Most Linux people already look down on their windows or mac using peers in real life. This combined with their lack of employment and need for superiority combines into this stupid rant about systems, bloat and other superiority nonsense.
Just ignore them. Most of these people don't have any productive things to do. They don't understand why people who are studying or working cannot keep fixing problems in Arch Linux or use something convoluted just for the sake of tinkering it 24x7. You just have to ignore these people.
sensitiveCube@reddit
Is this question being asked every week?
quintus_horatius@reddit
It's the latest religious war in computing circles. We used to see this with tabs vs spaces, and emacs vs vi.
Netizen_Kain@reddit
systemd's init is OK, besides being somewhat hard to troubleshoot but the other stuff it does, it tends to do poorly. And while in theory each of these components is modular, systemd being ubiquitous means that in practice changing them out is difficult or unsupported. I've had too many bad experiences with systemd components to trust it.
xebecv@reddit
Overly complicated configuration that somehow still doesn't cover some of my basic use cases. I remember how much shock I was in when switching from easy and intuitive upstart to a convoluted mess of systemd.
Some of my use cases: a timer that has not only a start time, but a stop time as well. Some of my services need to be active at night and inactive during the day and vice versa. Why do I have to write awkward separate stop timers for this? I also want some services to squeeze others out: i.e. you start one - it makes sure some others are stopped and never started until this one is done.
vinciblechunk@reddit
Because it almost got our shit popped (its needless complexity contributed to the xz backdoor)
calling_kyle@reddit
My very-surface-level is that systemd handles everything. Stars all the things video output, sound, networking etc. and this is not modular approach that is Linux is about (?).
cheesemassacre@reddit
It’s bloated. But it’s still pretty fast. I’m fine with it
eehikki@reddit
Lots of people are fucking morons. Being a moron is the only reason to repeatedly use standard, beaten to death, "arguments" against systemd.
BigusGeekus@reddit
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/
Bogus007@reddit
It violates the KISS principle, keep it simple, stupid, a core of UNIX systems. In detail it means that something has not do too much. Moreover, while Lennard said it will be just an initial system it starts to control mounting processes and network processes. I guess you know well, what kind of organism tells you it is a friend, and then becomes a foe? Right, a cancer. And this is systemd for those, who do not want a Linux to become a second Windows, who understand the in-and-outs of a system, the wheels which grab one into another to make your system work and where nothing is hidden behind a big bloated software. However if this will happen, and systemd is on a good way, it is time to turn to the BSDs or choose non systemd distri.
dasunt@reddit
Overall, my major complaint is that the project wants to do far more than just be an init system, and is designed to work with its various subcomponents.
I think that for software evolution, a system where components can be easily swapped out without a loss in functionality is going to see faster improvement as people experiment and try new things.
It's equivalent to having a shell where all the commands are built into it. It may be more convenient, but it also limits what you can run.
derangedtranssexual@reddit
Muh Unix philosophy
FamiliarImpress1873@reddit
any time someone puts "muh" I read it in sir sic's voice.
FamiliarImpress1873@reddit
people are dumb. systemd is good and simplifies everything, and manages system services well. "unix philosophy this, unix philosophy that" it works and works well for what we use it for.
teambob@reddit
People hate change
cocomac42@reddit
Take a look at this post over on r/archlinux - the answers their explain it reasonably well. Expanding on what u/ferric021 said, some tools (such as
ls) do one thing and try to do a great job of it. systemd... doesn't. Instead, it tries to do a whole lot of things (to name a few things - manage services, sync the clock, networking, and DNS) which not everyone likes. It can add convenience. However, some people would rather the PID 1 just do a good job of that and have other programs of their choice for other parts of the system without having it all bundled together with systemd.IMO, it's a trade-off. If it works for you, great! If it doesn't, feel free to check out something else.
Lastly, there's alternatives, and you can switch. But if you're using something like Ubuntu, understand that it won't be "just install a different one and see what you think". It might be "use a different distro"*.
*That somewhat oversimplifies it, but the point there is you can't "just" switch it in your OS.
cyphar@reddit
pid1 doesn't do timesync, networking, nor DNS. Those are all separate daemons that are part of the systemd project (just like how
ls,bash, andemacsare all part of the GNU project).cocomac42@reddit
Could you elaborate a bit, I'm not sure what you mean...? For example, in Arch, systemd-resolved is part of the systemd package, whereas I can have ls and bash without emacs if I want, yet I don't think I can choose that with systemd.
Equal_Prune963@reddit
You absolutely could but Arch decided to bundle every systemd component under the in a single package. Take a look at Debian for example where systemd is split up into multiple packages.
cocomac42@reddit
Huh. In Debian, they're under recommended (timesyncd) or suggested (resolved). I wonder why Arch did that...
MrElendig@reddit
Arch has a policy of following upstream packaging/naming and not to split packages downstream unless there are really good reasons for it.
Adding a bunch of confusion and complexity for the sake of saving 200kb of disk space doesn't make the cut.
Equal_Prune963@reddit
This probably has to do with their KISS philosophy.
Arch rarely does package splitting, which means that when you install a package, you get all the binaries, libraries, header files, documents and optional components, while other distributions have dedicated packages for those, allowing for a more fine-tuned installation.
cyphar@reddit
In addition to what the other commentator said, it should be noted that it would be a bad idea purely from a technical perspective to put all of these things in pid1 as well -- if any of this code had a segfault your whole system will crash. That's why all of these tools are separate daemons, even the ones that are pretty closely tied to the systemd project (such as udev, journald, dbus, polkit).
imsowhiteandnerdy@reddit
As someone who came from SVR sysvinit, it was mostly about adapting to something new.
whaleboobs@reddit
POETTERING!!!!! (old man yells at cloud)
I dislike sytemd, because I prefer dead simple stuff on my personal machine. E.g. Runit instead of OpenRC.
griso84@reddit
People is stupid
dgm9704@reddit
Check out this explanation by the Linux Experiment https://youtu.be/Fv3tQbOkz-E?si=nOM0cXHV7wYxFUoN
faxattack@reddit
Its easy to get lost in all new features, whose concepts are really needed mostly. BUT the man pages are very flat and confusing and systemd is moving very fast. If you fail to grasp it….I guess its easy to hate.
There are also lots of tooling that isnt really getting any good attention so it all ends up in a confusing mess on how to handle things properly.
throwaway9gk0k4k569@reddit
What attempts did you make towards validating criticism towards systemd? What criticism did you find valid, and which did you find invalid, and why did you come to those conclusions?
And why is the answer that you didn't even try before asking to be spoon fed instead?
sleemanj@reddit
Because I don't like having to search for incantations to find things that should be trivially discoverable in the filesystem with ls, find, cat, and grep.
I guess it's a bit the same as asking why people hate on systemd, over, and over, and over again, instead of using the search.
FlowVonD@reddit
I think 99% of it are butt hurt neck beards that didn't get over people telling them that their precious init service is outdated and systemd is the future. that combined with years of forum posts and people hopping on the band waggon lead to what we have now. while it might have its issues the truth is it's very convenient. and since Linux is how Linux is with all the choice and customization it just happens that people will defend their favourite tool like it is their child..
khamzatsmom@reddit
Because they repeat what other people on reddit say
BigHeadTonyT@reddit
Among the other things, this:
https://www.reddit.com/r/linuxmemes/comments/1diq10c/systemdtmpfiles_purge_can_delete_home_in_systemd/
To me, that goes against "Do not mess with Userland". Yeah, Kernel mantra. But to me, it applies everwhere. Deleting your home folder? Bad. I don't remember if it even asks if you are OK with that. If a Dev deems that acceptable, what isn't?
SystemD (I don't care how it is supposed to be spelled, eat me) is trying to do everything, Sounds like Microsoft to me. I am not suprised Poettering ended up at Microsoft.
Business_Reindeer910@reddit
that meme post is issue is fixed in the next release. But as far as 'messing with userland". You triggered that issue by using systemd. It's just that the docs were bad for that.
GirlCallMeFreeWiFi@reddit
IDK, I love it. I understand basic usage, not difficult operations and how it works. for my understanding level it is intuitive and easy to use.
Obvguy@reddit
Because, it cannot coexist with other init software. For eg. I cannot fully remove systemd from Ubuntu and most other distros and install other init software like Openrc, runit etc.
Because, it is a sponsored work to change the Linux ecosystem. The intentions may not be nice by corporations or governments.
chrisjob102100@reddit
I wrote some systemd hate on here a while, half jokingly, and got downvoted a bunch. For me, it’s just that I grew up with Slackware and init.d and it’s hard for me to let it go.
LiberalTugboat@reddit
It's just people spouting things they heard from neck beards on YouTube.