I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.
The arrogance of Lennart has something to do with it.
The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right.
Numerous cases of that.
Then the security aspect of a jack of all trades process running as one that controls every other process.
Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, reading and parsing logs the same.
There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.
The above doesn't represent my personal opinion, it's a representation of what reasons people might have.
> There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.
I only learned about that a few days ago, here on HN (some thread or some old comment).
It is completely insane and gives lots of fuel to the systemd haters.
I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff removed). I use Devuan on my main desktop PC and I've got exactly zero problem.
That's the thing: many "sell" systemd as some mandatory machinery but it simply ain't. Ultra-light containers (like Alpine-based ones) run fine (and faster) without systemd. Desktops do run fine without systemd (I'm running Devuan on my workstation and Debian on my laptop: it's basically the same experience). For certain types of servers I can understand some see benefits in running systemd.
Neither IBM / Red Hat nor Microsoft should be those setting the terms of what is or is not an acceptable "PID 1" for Linux.
The day Linux becomes "systemd Linux" is the day I'll switch to a BSD.
I don't mind that systemd exists as long as people still have the choice to run a non-systemd Linux. The kernel should be orthogonal to systemd and there should be Linux distros packaged without systemd.
And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing.
> and there should be Linux distros packaged without systemd.
systemd should be an optional package on all distros. Shoving it down throats is one of the valid major criticisms. What should have happened instead is systemd was optional on Debian at setup and Debian was forked to include it by default. It is simply backwards that Debian needed to be forked for purity. Duvuan shouldn't need to exist, but it very much does.
The entire ideology of openness and freedom has been turned on its head. Instead of "what is best for everyone is good enough for me," has become with entitlement "what is best for me is good enough for everyone." Maybe you like the way you do things, but would any here really insist on forcing everyone else to use your methods and no others?
systemd, among other valid criticisms, is unmistakably fascist. For anyone but parent, don't just be thin-skinned and downvote my comment because you have allowed yourself to be insulted. Be courageous and disagree with me if you can. How is systemd not fascist?
>systemd should be an optional package on all distros.
Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what defines a distro and sets it apart from the rest. If they have limited manpower and choose to save themselves time by picking only one init, or libc, or desktop environment, or anything, that's their decision.
>but would any here really insist on forcing everyone else to use your methods and no others?
No. There are hundreds of Linux distributions to choose from, and anyone can make more distributions any time they want. No one is forced to do anything. Also, using Linux is optional to begin with.
>systemd, among other valid criticisms, is unmistakably fascist. For anyone but parent, don't just be thin-skinned and downvote my comment because you have allowed yourself to be insulted. Be courageous and disagree with me if you can. How is systemd not fascist?
You should stop and think a bit more before making these comments that you appear to be acknowledging as histrionic and insulting. By this definition BSD is also "fascist" due to only shipping BSD init, and the Linux kernel is "fascist" due to only shipping one set of drivers, and Devuan is also "fascist" for not supporting systemd...
Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel. They pretty much do what is expected, sometimes they do more, but not by much.
Systemd? It is not a good replacement for an init system for the users. Instead, it is an OS functionality accretion for the benefit of distributors, a baroque monstrosity that provides mediocre buggy solutions to too many problems that have nothing to do with init. It boots nondeterministically (socket activation is not such a universally great idea), sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition, or launching zillions of bogus hog processes for every user login event. Some of these can be mitigated on a production server, but bad taste remains.
>Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel
That's subjective. I've talked to a lot of Windows users who all say Linux is a terrible solution for them. I don't think most Debian developers feel they should suddenly drop everything and start making Linux exactly like a copy of Windows just to please those people. They voted on this several times, they wanted systemd.
>it is an OS functionality accretion for the benefit of distributors
There's no problem with this. Most users don't touch the init system that much. They interact with it primarily through the package manager installing service files.
>solutions to too many problems that have nothing to do with init
Those are all optional add-ons for users who are having thoes problems.
>It boots nondeterministically (socket activation is not such a universally great idea)
This is also only an option. You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.
>sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition
> That's subjective. I've talked to a lot of Windows users who all say Linux is a terrible solution for them.
That's a different statement. I said those linux parts are good solutions to a libc library and unix kernel. Not good solutions to needs of Windows users.
> Most users don't touch the init system that much.
Most BFU users don't touch the init system. If you're a developer/administrator/power user, you do. Yes there is more BFUs (website users, android users) than power users, but that does not mean that the latter group should be pushed to not care about their init system.
> Those are all optional
Not in practice; some of those options are integrated and others are chosen by the distributions. It's hard to reconfigure the system to opt out of journald or user session control.
> You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.
Yes, but that won't solve the problem entirely, systemd is non-deterministic init system where you can't fix the boot order reliably.
> Not sure what this means or what keyboard input you were pressing. In systemd the keyboard shortcut to force reboot is pressing Ctrl+Alt+Del 7 times
Ctrl+C, Ctrl+Z. I mean I don't always want to reboot because something went wrong in the boot process and systemd is stalling. I want info from my init what went wrong, and the option to fix the problem in the shell if possible. This is often not allowed by systemd when it could.
> Not sure what this means either. You can disable those.
It means systemd launches bogus processes slowing down the system. It's well known, it's in the trackers, yes I can and i do disable them.
The point is this sucks and neither the systemd developers neither the distribution(rhel and derivatives) care to fix this.
> Should glibc also be optional? What about the Linux kernel? What about apt-get?
In my opinion, yes, they should absolutely be optional. Whether or not that is feasible today does not change the advantages of each component of the system being optional and replaceable. It is more failure tolerant both from a purely technical perspective, and also from an organizational perspective.
If you're only talking in hypotheticals then they're already optional and replaceable. Someone just needs to do the work to replace them.
You're missing that these parts have to get replaced for a practical reason. Not just because someone vaguely feels it would be more fault tolerant. For example, think of some other libc that's optimized for a certain hardware. Distros that don't support that hardware would have no reason to ever use that libc. If you say all distros should support it, then your opinion is really "all distros should support this random hardware that might be rare, expensive, highly specialized, hard to develop for, etc" and now that's a much more complex and demanding task you're asking someone to do, for very little benefit.
I'm not saying that every distro should support every piece of software that's out there, that would be wasteful and very difficult.
What I am saying is that, ideally, every component in a distro (or any important software, really) should have at least two options, so that if one option fails for whatever reason, the user has a choice to swap it and keep working. This is already true with many components of a distribution.
This is how I am writing my application. It is not fully there yet, but I plan for every dependency to have an alternative. I also favor dependencies with long streaks of no breaking changes, having been previously affected by breaking changes in dependencies I was using.
The primary definition of fascism, according to the Merriam Webster dictionary, is this:
> a political philosophy, movement, or regime (such as that of the Fascisti) that exalts nation and often race above the individual and that stands for a centralized autocratic government headed by a dictatorial leader, severe economic and social regimentation, and forcible suppression of opposition
systemd has nothing to do with nation or race. There are much better words than fascism to describe Debian's prioritization of systemd.
Thank you, and a worthy attempt, but as you have defined Fascism, the political movement and a noun and proper name, as opposed to the adjective fascist, as in advocation of an authoritarian regime and in opposition of and intolerant of opposing views, and in modern definitions, a synonym of "bullying," your post is somewhat of a straw man. Obviously I was not suggesting that systemd was literally Nazi software. What I was saying is that systemd, as an unnecessarily complex machine in itself as it proceeds to annex other parts of the system, is autocratic, strongly regimented and centralized, suppresses opposition, and subordinates individual interests.
I would suggest a better word to describe systemd design philosophy is authoritarian, if we're going to stick with political science terminology.
Human systems tend to flourish when political and economic decision-making is relatively distributed throughout a given population. I believe this position is backed by a reasonable amount of empirical observation.
Machines are (as of this writing) programmed by humans. Unlike humans, machines are automated rule-followers. This is substantively different from decision-making, which is a uniquely human trait involving moral agency, free will, etc. (at least as I'm defining it for the purposes of my argument). If you try to turn humans into automated rule-followers by decree, they tend to become miserable. Fortunately, one does not have to take into account how machines feel about being absolved of all decision-making, making such control systems very effective (you don't have to kill / imprison the dissenters). But even though the machines might be more effectively programmed by a centralized, unified, top-down, "authoritarian" control architecture, you still need humans to build this controller. And since we know software projects end up mirroring the communication structure of the humans in charge of building them, it follows that authoritarian-minded software engineers would be a best fit for building such systems.
The converse is that libertarian-minded software engineers tend to recoil in horror when they encounter authoritarian software design, no matter how unified, elegant, or effective it may be. Such things are a moral transgression to the libertarian.
And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing.
All the changes to gnome, which depended 100% upon systemd at the time, were pushed by redhat, gnome contributers.
This one of the biggest reasons given, for getting systemd into debian at the time.
When systemd was being pushed origionally, fast boot times, predictable names, and a few other things were big reasons. Yet debian already had parallel init booting, and already had predictable interface names.
Systemd has done almost nothing for debian, and has many drawbacks, as you say.
Systemd was a redhat solution, to redhat issues, and redhat used its power in the community to force it through.
There were a lot of outright lies, politics, and more at implementation time. And you're right, part of it was redhat wanting to force systemd, and no other.
But debian has chosen to adopt systemd, so at least some substantial part of Debian developers preferred going with it to keeping the status quo with sysvinit. Maybe they were badly influence by Redhat/Poettering, but it was their call.
Of course they were influenced by the author of programs they use. They were also influenced by Linus Torvalds when they decided to use his kernel. I don't see any problems with this. That's what you do when you make something that you're proud of. You go around to other people and try to convince them to use it.
> It is completely insane and gives lots of fuel to the systemd haters.
Sorry, what exactly is the issue with a bunch of Linux maintainers working for Microsoft? Is there still some sort of collective adjustment issue with Microsoft being a major backer of Linux now? If the maintainers themselves (people who have dedicated their lives to progressing Linux) are ok with it, why does anyone else have an issue?
And what kind of fuel would it add? That systemd has corporate backers?
> The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish.
And now they're one of the major backers. All the work is being done in the open, so it's not like there's a nefarious hidden agenda there (an agenda that would have needed to somehow stay dormant for 10+ years).
The idea that working for Microsoft is something dirty that should be shunned for open source just doesn't make practical sense.
Embrace and extend is a fundamental part of the OSS model. That's what you're supposed to do: pick some OSS, make some custom add-ons to it, then upsell it to your customers. The license encourages everyone to do this. Tons and tons of OSS companies are doing this. Microsoft isn't doing anything out of the ordinary here.
Just a reminder holding grudges isn't good for your mental health.
Microsoft pushes ads, surveillance software and broken updates on most Windows users. That they are buying influence in Linux and throwing some money at it does not absolve them. Working for bad behaved corporation isn't laudable unless you're literally saving lives there.
Err that seems like an unreasonable (and child-like) simplification of the world.
Microsoft has done many terrible things. Most companies of that size have. But they have also done a ton of good things. It’s impossible to take a group of tens of thousands of humans and not find rampant examples of both good and terrible things.
Sometimes one outweighs the other and that may sound like where you are but there is a wide gap between doing evil and saving lives, and most of us live somewhere in that gap.
I totally get it – I've watched it all unfold over the last couple of decades.
But everything I see since Nadella has taken over, tells me that they aren't just paying lip service, that they have just realized nearly a decade ago that it's good business to embrace (loaded word) Linux if they have any chance for Azure to succeed, and their moves suggest that's a core part of their future.
> There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.
Yeah, well... Microsoft is probably soon to be one of the bigger Linux developers out there. As the profit slowly drains out of the desktop their core business model is going to be increasingly dependent on open source and Linux.
Just in case anybody reading this is a big fanboy of Linux... This is what winning feels like.
I don't know about your experiences, but systemd is leaking preconceived notions and self-imposed limitations like a broken sieve where one is left to sift manually through documentation and bug-reports, collecting and evaluating rules, exceptions and idiosyncratic notions to determine whether systemd will do what one wants.
Latest example: I have a service I want running, so I set it to Restart=always. Read the long Restart= documentations - seems ok. Does it work?
Failure 1: Well.. you also need appropriate RestartSec/StartLimitInterval. Ok, I I set it up. Does it work?
Failure 2: Well.. restart doesn't actually apply to failed dependencies, so .. don't have dependencies that fail, ok? That's not a bug. [1][2]
Systemd is a somewhat successful non-unix operating system, marketed to people who want a unix-like operating system using force. This isn't what anyone wants but you'll go along or they'll unleash a hell of sophistry about how this is "really" what everyone wants even if its the opposite, made up stories about the opponents, or only bad people don't want what we want and you don't want to be tagged as one of the bad people so you're gonna say you officially love systemd, correct?
It would be like going to the EV car dealership and being told the best modern EV they sell is a diesel pickup truck and they will unleash sophistry hell on anyone who doesn't go along with their meme that the best modern EV is obviously a diesel pickup truck but pointing that out in public is doubleplus ungood badthink.
Ironically, for a non-unix-like operating system, its not that bad and works some of the time, although not as well as a unix-like OS would work for someone who's engineering criteria is a unix-like OS. Most people would be technically better off with a unix-like OS than a systemd based OS, but thats not what the corporate marketing department is selling, so we all love systemd, uh huh.
Linux+GNU is either a Unix operating system or it is not. Having systemd on board changes exactly nothing, since there never was a system services interface anyway. Files in a directory you say? That's not an interface, it's a recipe for failure. Or why do you think that every distribution used to ship their own init scripts?
You EV car dealership is awfully flawed, especially with Linux+GNU you can even build you own car. So why are you complaining? Nobody is forcing you to use a distro with systemd. Nobody can force you. You're not a victim, you're privileged.
systemd is for the first time providing Linux+GNU with a sane system services management and finally gets it ahead of OSX or windows in terms of capability. Instead of unconstrained bash scripts (that require ridiculous template magic or fail for the first edge case) you need only a ten line service description that does things that an init script would not been able to deliver. Like the most basic thing ever; reliable restart. The amount of hacks that were necessary to get an init script to only semi-reliably restart are atrocious - and deamontools are just the beginning.
I've come to understand that the dislike of systemd has less to do with the technology at hand but more with human nature.
You're right that systemd provides useful things that sysvinit was not strong about. That is not enough to make systemd as distributed a good init system. It is a bloated C codebase with no definition of goals, instead it suffers never-ending mission creep.
In mainstream distros, while it does init, it also meddles in too many things it should not, like spawning zillions of needless user session processes hogging the system, mutilated system and service logging and others. It hangs randomly nondeterministically on boot too often, disrespects the user by ignoring keyboard input, etc.
The major point of critique of systemd push is to make people know that many don't like the offered product for its mediocre results as an init system, and uncalled for meddling in other business such as system logging. And we welcome new leaner init systems, such as s6.
systemd ist not an init system and it never was intended to be "just" an init system; from the very start was conceived a system services management layer.
If there's an expansion of scope in the systemd project, that's because these use-cases were not sufficiently covered in the past. And while I wish you good luck with s6; how do you intend to replace all the functionality that systemd already delivers?
Let's pick an example; KDE and Gnome used to write their own session management software, to make sure certain applications and services that the desktop needs (like; e.g. accessibility tools). This is nowadays handled by systemd, since it - as a system services management layer - already implements all the required functionality. So instead of three half-backed systems (one by KDE, one by Gnome, one for the system, all incompatible and unable to talk to each other) we have one good implementation. User session are also now handled in systemd - one less component to be developed by the "Desktops" - yay!
Where you see feature creep I see consolidation. A consolidation that - in my opinion - is painfully necessary.
> these use-cases were not sufficiently covered in the past.
Many systems do not have those use cases. Everybody needs an init system, so that's where systemd could have been the fix to the deficiencies of sysvinit (as marketed). Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong. And then instead of fixing and polishing that experience, developers expanded into million other directions, including DNS, container management and what not. Systemd is becoming a bad OS like Windows is.
> User session are also now handled in systemd - one less component to be developed by the "Desktops" - yay!
But systemd is used on servers too, and the user sessions and broken behaviour it introduces are a needless pain best to be disabled there. User sessions and related is really something Desktops should be handling, since it only makes sense on Desktops.
> Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong.
I have never experienced that kind of errors you describe and I use Linux+GNU on my private workstations, on my professional workstations, on various servers and some NAS devices. Is there a bug report that documents these failures?
> Systemd is becoming a bad OS like Windows is.
Systemd is a system management layer, the operating system is GNU+Linux.
> User sessions and related is really something Desktops should be handling, since it only makes sense on Desktops.
You can disable it, if for some reason you get errors. Never had issues with user sessions on servers either.
> and you don't want to be tagged as one of the bad people so you're gonna say you officially love systemd, correct?
That does seem to be like weirdly a thing with redhat projects. I once saw someone say that being anti-systemd was correlated with supporting trump on hackernews, and of course if you don't like gnome you hate accessibility and poor people (who apparently don't know how to use less hobbled/phone-like user interfaces).
It's quite simple: many people had atrocious experiences with systemd.
Systemd ruined Debian for me, for example.
I'd been using Debian testing for years and years, on multiple systems. Despite its name, I'd always found Debian testing to be more reliable than the stable releases of other major distros.
When performing updates and upgrades during those many years of using Debian testing, I had only ever experienced trivial issues that I could easily resolve, usually just on my own with a few minutes of investigation.
Then systemd was forced onto Debian's users.
As soon as it ended up on one of my systems, the problems started. That very first update left my computer unable to boot. That was the first time in over a decade of using Debian that that'd happened. I also remember it taking far too long to diagnose and resolve whatever that initial problem was.
Subsequent updates involving systemd just caused me more and more problems. They usually weren't minor issues, either. They'd significantly impact the usability of my installation.
To make matters worse, I, as a user, didn't see systemd even bringing me any benefits.
Eventually, I lost my ability to trust in Debian and its reliability, even for Debian stable once systemd eventually made it there.
Now I completely avoid Debian and other systemd-using Linux distros whenever I can.
I recall part of the problem was that in some cases, Debian packagers/developers did not know how to integrate systemd with sysvinit properly, there were weird problematic constructions such as sysvinit scripts calling systemctl or vice versa and some breakage due to the way they used systemd. Of course, one could ask whether this was partly due to bad systemd documentation and unfulfilled expectations of promised systemd behavior.
I think it just has many details you can end up hating, so a person will inevitably run into one or two.
I myself don't have a problem with the monolithic thing that replaced sysv init scripts. While the definition of sysv init scripts was attractively simple, the resulting implementation was not. Wading through many lines of boilerplate shell that's mostly accidental complexity is not my idea of a good time.
But I do hate how systemd splays its config and dependency graph throughout hundreds of tiny files and symlinks in multiple directories (and .ini files at that!), and then insists that this is no problem because you can "just" learn some bespoke commands to analyze them for you. With my sysadmin hat on, I'd much rather have a unit be a single file in a single well known directory, that specifies only the service properties and no dependency information. And then have the dependencies orchestrated by a single logical top-level file that pulls those units in and defines what depends on what. In general if I'm going to customize a distribution-supplied config file, I'd much rather overwrite the distribution file and completely own it going forward, rather than having the distro file and my file merged with some arbitrary rules.
Having said that, I've moved many of my machines to NixOS where systemd is just another thing to be mitigated and nixified. The expected on-disk format doesn't matter, because it's all generated from a single logical config file and then splayed out however systemd wants. The nix config looks a bit verbose and wonky, but at least it's contained. But it also feels like it would be quite easy to switch out down the line...
While systemd does have many good features, it also has failed to turn computers off on various systems and distros. I repeat: failed to turn computers off. This wouldn't be acceptable in beta quality software. But it's systemd and for whatever reason gets a free pass on failure to do incredibly basic things.
At the very top of this page, there are two features listed which will be removed in the future.
This means that anyone who relies on this feature is now tasked with all the extra work and cognitive load of finding replacements for those features, changing and testing their configuration, and the risk of deploying these changes.
To me, that is a "non-consensual" change, and I try to avoid any technology that has a history of these non-consensual changes, because I want my systems to run without extra maintenance.
> To me, that is a "non-consensual" change, and I try to avoid any technology that has a history of these non-consensual changes, because I want my systems to run without extra maintenance.
Then stop using Linux. The Linux kernel replaces subsystems with different, incompatible subsystems all the time. For example packet filtering was once ipfwadm then ipchains followed by iptables and now nftables.
It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend.
How long until “Systemd: The Good Parts”?
*The most trivial new name would be système which would at least be in keeping with the French naming.
**In Debian stable if you create a new user, ssh in as that user, logout, then delete the user, you can’t because systemd is still running a detached housekeeping process as that user. If you wait a bit then the systemd process goes away but that, to me, makes it a worse bug not a better one.
> Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see the options KillOnlyUsers= and KillExcludeUsers= below.
> In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1).
> Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).
The "scandal" was the exact opposite of your complaint. People where SSHing in, starting a screen/tmux, disconnecting and complaining about the process being killed.
Not really an exact opposite. There was a preexisting convention for how to intentionally keep a process running after logout, which systemd broke. That's quite different from a case of a background process the user did not explicitly ask to be started in the first place, let alone flag to keep running after logout.
You mean the distros broke it by not toggling that option. As you can read from the parent comment here, that "convention" was also broken and causes issues in Debian. There's no solution here that isn't going to break something, that's why the best systemd can do is ship a toggle and tell the distros to figure it out.
There were a lot of noises made about it, yes, because people had been "nohup"ing things for decades, and using stuff like screen and tmux to keep sessions going over poor connections.
All of a sudden, without much warning, someone made the decision to kill all user processes on logout. It broke a lot of folks workflow.
Don't we already have multiple, alternate systems that are significantly simpler?
The primary reason why I don't use systemd at all, on any desktop or server I manage, is not that I think it isn't powerful or reliable but, I cannot fit it into my head.
The scope and complexity of it goes beyond what I'm personally willing to invest into any one subsystem designed to regulate my operating system.
I find that because I can't easily integrate day to day systemd operations into my general knowledge of the Unix / Linux shell environment, it essentially creates a cognitive switching cost that I'm not willing to pay given the efficiency and utility I get from my existing knowledge and skills.
Systemd seems to work well for a lot of people, but doesn't sell itself to me given my objective, and capacity, to internalize simpler tools for high levels of mastery.
That's why I don't use systemd but do use other, more simpler systems, that are readily available.
In lot of cases I've found systemd units much to actually be simpler and easier to maintain due to everything being in a simple declarative format. The old alternative is to have a lot of shell scripts that can get very complex, and to consult another few hundred man pages for various shell utilities...
True. However, my objective is to internalise the tooling that routinely use, the scope of systemd is beyond what I need. Also, I find constantly looking up unique directives fatiguing and would rather use that energy elsewhere. I find working with the same general tooling results in faster & easier mental recall across a broader range problems that I tackle. Just my experience, no doubt different for others.
This is such a superficial and ignorant take I'm having hard time forcing myself to believe it was written in good faith.
Dozens of alternatives already exist. The problem isn't writing, problem is having politicial power Poettering had. (ie. He was employed by Red Hat and had close connections with other Freedesktop developers.)
That isn't "political power" it's called knowing your audience and knowing what they want. The audience here is Linux distribution upstreams who also participate in Freedesktop. The other alternatives had ample time to talk to these people and copy the features of systemd and improve on them but they refuse to do it. They seem more interested in building for their own niche use cases and ignoring everyone else. That's a fine decision, but it's their decision. They can't say it's anyone else's fault.
Edit: If those other developers were really serious about trying to replace systemd they would be going around to every distro maintainer they can possibly find and asking them what systemd is doing badly and what they'd like to see in a better project. Then they'd have to think really hard about whether it's easier to fix those issues just by contributing to systemd, or whether a full replacement is warranted. Every now and then I see comments about writing replacements in Golang or Rust or some other memory safe language but there's no other interesting ideas there to warrant a rewrite. Maybe you do all this and conclude there are no major complaints from the big systemd users, and that's just how it is.
Yeah, but Redhat has been slowly getting control of more of the infrastructure. Want to make your own? Well even if you make something backwards compatible with Gnome or udev, get popular and they will probably find some way to break your compatibility.
You end up needing to fork all the projects that Redhat has gotten their tentacles around.
That's a pretty negative way to make an innocuous statement: that it's expensive to make an OS. You can't expect Red Hat (or any other Linux company) to maintain backwards compatibility forever for every single possible project they've ever had an employee contribute to. They'll maintain some as long as their customers pay to support it for that long, but even that ends after a while. Yes, if you don't want to pay them for it, then you get to spend the immense amount of time and money needed to fork it; because shipping a full commercial operating system with millions of lines of code is a complex task with a lot of interlocking parts and no one wants to do it for free. It makes no sense to single out complaints towards random projects for this.
>It was killed because of the Red Had power behind Systemd.
That is an absurd, untrue conspiracy theory. Whoever told you that should be ashamed. The author of Upstart said that it died because of a restrictive CLA. Read the thread linked here for an explanation: https://news.ycombinator.com/item?id=27176807
To quote the relevant parts:
>I entirely agree with Kay and +Greg Kroah-Hartman that it was the CLA that caused systemd to be written instead of Upstart.
>But I don't need that self-affirmation anyway :) I wrote Upstart, I got paid for it, I moved on to do other things, something else came along and replaced it. If Upstart hadn't been under the CLA, and systemd hadn't've happened, all my code would have long since been rewritten by now anyway.
Just because the project is moving, doesn't mean it's moving in the right direction.
What I like about linux in general, is that there are lots of small tools, with a reduced and specific scope, that do their job well. Systemd seems to want to do and control everything.
I don't know if it was intended, but "système D" in French means hacking together something with whatever you have available. D meaning "démerde" (literally getting out of shit or a shitty situation) or "débrouille" depending on the language registry you want.
“[The] name is suitably reminiscent of the French term "système D", an expression that relates to thinking on your feet and describes high-speed technical problem-solving abilities such as those displayed by TV action hero MacGyver.”
Interesting. However, the link they provide as reference where apparently "The developers thought that its name is suitably reminiscent of the French term système D" does not have this term anywhere. My guess is this was just made up by a 3rd party (h-online in this case) and everyone just went with it?
I have that c't magazine they're referring to somewhere, I'll look it up there
I expect there will be a system that is not necessarily less complex (as what systemd does IS quite complex); but is more:
* safe (uses Rust with unsafe)
* modular (systemd is pretty all-or-nothing)
* open access (less RedHat dominated)
Probably it will be using some of the same standards as systemd or at lease be BW compatible to some extend. Once Debian picks it up, it's game over systemd.
About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times.
The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.
The kernel initramfs only mounts the root partition - parsing fstab and running mount is handled as part of init. This means that an init system needs to support split-usr by ensuring it can go without the contents of /usr at least long enough to bootstrap (which requires special treatment of the mounting scripts/units) or else avoid using /usr at all
"From: Adam Jackson
To: Development discussions related to Fedora
Subject: Linux is not about choice [was Re: Fedora too cutting edge?]
Date: Wed, 09 Jan 2008 15:58:45 -0500
> Linux is about choice.
If I could only have one thing this year, it would be to eliminate that
meme from the collective consciousness. It is a disease. It strangles
the mind and ensures you can never change anything ever because someone
somewhere has OCD'd their environment exactly how they like it and how
dare you change it on them you're so mean and next time I have friends
over for Buffy night you're not invited mom he's sitting on my side
again.
As a consumer, yes, you have lots of choices in which Linux you use.
This does not mean Linux is in any sense _about_ choice, any more than
because there are so many kinds of cars you can buy that cars are about
choice.
The complaints up-thread about juju and pulse are entirely valid, but
the solution is not to try to deliver two things at once. If you try to
deliver both at once you have to also deliver a way of switching between
the two. Now you have three moving parts instead of one, which means
the failure rate has gone up by a factor of _six_ (three parts, and
three interactions). We have essentially already posited that we have
insufficient developer effort to have 100%-complete features at ship
time, so asking them to take on six times the failure rate when they're
already overburdened is just madness. Alternatively, we could say that
we're integrating features too rapidly, but you do that at the expense
of goal 1, to be the showcase for the latest and greatest in free
software.
Software is hard. The way to fix it is to fix it, not sweep it under
the rug.
There is a legitimate discussion to be had about where and how we draw
the line for feature inclusion, about how we increase and formalize our
testing efforts, and about how we develop and deploy spike solutions for
corner-case problems like the one device class that juju happens to do
worse than the old stack. But the chain of logic from "Linux is about
choice" to "ship everything and let the user chose how they want their
sound to not work" starts with fallacy and ends with disaster.
Hah, I knew somebody was going to post this and almost added a disclaimer.
When I say Linux, I'm talking about Linux distributions. Not the bare kernel, not embedded Linux.
If I choose to use Linux over macOS or Windows, the #1 reason is that it gives me greater choice. On the desktop, to choose different desktop environments, to customize it to a greater extent than what is possible on other platforms. (That even applies to some extent to the server, I can choose from a greater selection of alternative services and am more flexible than in the Windows Server world, where it is more often a IIS, MSSQL, .NET stack.)
If I don't value choice, than frankly there is very little to make me choose Linux over whatever is preinstalled on my Laptop. I used to have fun tinkering with my Linux installation and developing my own tools and workflows etc., but now that I'm older and don't have so much disposable time I prefer something that is good enough out of the box. I'm sure many people can relate.
If the greater Linux community still embraced "Linux is about choice", and I could still run stuff in the "mix and match" spirit of ca. 2009, but with a modern kernel and modern apps, then I would immediately switch to desktop Linux. But you can't choose your window decorations, themes, desktop panels independently anymore and get a somewhat matching look and feel. It's only Gnome island, KDE/Plasma island, and hacker-minimalist island.
>But you can't choose your window decorations, themes, desktop panels independently anymore and get a somewhat matching look and feel. It's only Gnome island, KDE/Plasma island, and hacker-minimalist island.
Maybe take that as an indication those "spirits" are at odds and can't be reconciled? You can't have a system that's fully stable and predictable but also lets you swap out any component at a moment's notice to some unsupported third party thing. You either pick one or the other. In my opinion Linux has only ever been really worth it for companies willing to employ developers to work on it; you don't get any of that customization for free. At one point Linux companies were experimenting with things like desktop panels but then the market changed, they stopped and the money dried up. That's what happens.
I am thankful for the non-systemd distributions, which are listed at https://nosystemd.org ; just scroll down to the list if you want to skip the advocacy.
I have found FreeBSD to be very coherent as a Unix; and the documentation is very well written. Jails, once understood, seem very good also, even if not perfect.
I love systemd for deploying Golang, especially the security features, that systemd can own the TCP port for zero downtime deployments of the application and restarts of a fail-fast application. It kind of replaced Docker (dockerd) which I've used with deploying Scala and TS.
I once won a backdoor contest by installing a systemd socket who launched /bin/sh as root. At this point, people don't question why systemd is being bound to some random ports.
But then you should only get the users account as shell, so while this is a neat trick, being able to gain persistent root if you are already root is not that hard.
systemd doesn't bind to random ports without being told to. if the blue team didn't stop and say "why is anything listening on port %d", they're a trash blue team.
Clearly you have not used systemd and friends much.
It is an ecosystem of daemons that does a lot of things, some of which are guaranteed to surprise you. The specifics of which will vary between releases.
I could easily see some random systemd utility binding a non standard port without anyone taking notice.
That would be the distro's problem, not systemd. Any of those utilities are going to be optional, the distro has to consciously enable them and ship them in a package for it to make it to you at all. A lot of commenters seem to misunderstand that systemd is not forcing distros to do anything. All they really do is provide a set of tools for distro maintainers to choose from.
I remember using xinetd, and while xinetd does do the job… sometimes… systemd is much more comprehensive, so you don’t need to fuss about with different configs for xinetd, cron, init.d, etc. This is especially nice since the number of config options has skyrocketed, so systemd really simplifies administration (in my experience, at least).
Isn't it astonishing? I've been using Linux pre-Slackware with downloading boot.tgz and root.tgz on two floppy drives, wrestled with M4 and sendmail, have been writing internet applications for 35+ years but never used a Linux daemon to manage my applications. You're never too old to learn I guess.
I use systemd at work and I have finally learned to love it. Still don't like binary logs but the timers, watchdog and sandboxing features are wonderful.
It's great, you can have it launch multiple processes on the same port using SO_REUSEPORT. Normally it'd be a bit of a pain to health check multiple processes running on the same port without some other machinery since it is possible to get into a state where all but one process is hung. Systemd watchdog will provide your service with a socket and expect updates on a regular interval or else it will consider your service dead. This socket is also very handy for service startup, to have your process just notify systemd it is ready rather than having to poll to see if your process is listening yet.
It's zero downtime in that at no point does the kernel not respond to a TCP SYN packet and all those connections eventually get seen by the daemon. (Really useful for updating local services on Unix sockets.)
It's also much simpler than redundant instances, and applications are updated much more commonly than hardware failures so it's a cheap way to increase availability in practice.
And if your app can restart in a couple seconds... It might as well be zero downtime, and if not responding for a second is an issue, you have bigger issues.
Using any kind of network that isn't hardwired to the server will break that. (Cellular, WiFi, roommate starts downloading an update over DSL, etc)
Even just having other services on the server spike in usage can break that.
Also I'm talking about "100% of requests finish in 100ms", which is damn near impossible, vs "99.9% of requests finish in 100ms", which is very doable and having a couple seconds a day you don't respond isn't going to break that.
I have long been an advocate against systemd for the typical reasons (overreaching responsibilities, lock-in, lack of choice, software assumption "it will be there", complexity, driven by large corporate interests [see lock-in], being modeled after launched, etc etc). I feel like the chickens are coming home to roost.
That said, if one wants to use it, then use it. However, there are alternatives which I would love to see receive more adoption. I've been extremely happy with my Artix [1] system running s6 [2] init.
Why s6 over other options? I've long considered switching from arch to something without systemd since I use almost zero systemd features but have not had time to discern which init system to use.
Mostly because of the philosophy of the software's author. This was the selling point for me. It is incredibly small scoped by design, easy to understand, and is very explicit in it's actions. It is not as "user friendly" as other inits, though the author is currently working on making it more accessible. It practices separation of mechanism and policy, it attempts to do less than more, and it know when to stop and not introduce scope creep. All by design. I won't ever have to worry about it becoming a system layer and reaching into my network stack, or making policy decisions for me.
I'm sure other available init systems have their selling points - but to be honest, after reading s6's reasoning and design goals I was sold. I'm happy to report that after a year and a half I'm pleased with the decision.
Thank you for this information. I was leaning towards other init systems for the potential future where I switch to artix simply due to recommendation, I will reevaluate at some point. Thanks again.
SystemD fundation basement was a Linux implementation of the MacOS LaunchD. It was a step forward over the traditional init managers, but in any case disruptible over something new, because an equivalent design was running on Apple devices time before.
upstart was terrible. I wanted upstart to win, I invested a ton of personal and professional energy into making it win, and it was all a terrible mistake. The design was simply backwards. systemd was right from the start.
I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?
I think generally people view timers as a net superior alternative to crons: they have better logic for the times, they support dependencies, they support randomized delays, etc. Why do you think they're a real mess?
I guess their UX for a simple cron-like use-case. I remember trying to set it up and it wasn't a great experience. Just trying to see if others agree or not.
Systemd timers are more complicated than cron, but there's a reason for the complexity. Once you've put in the extra effort to understand the logic, they're really powerful.
If you don't want the complexity, then just run crond.
Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
From an outsider perspective these stick out to me as most important:
- Unified logging subsystem
- On-demand launching, memory limits, and general resource management
- Advanced security features, i.e. sandboxing, DynamicUser
- Well thought out and implemented given the constraints (feels like Linux quality)
In general it represents a shifting of code from daemon developers (who previously handled daemonization themselves) to the system.
On-demand launching is good for performance: work can be deferred from boot and inactive daemons can be stopped. This is critical on battery and RAM constrained devices
I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.
Yeah, imagine if Windows was made up of many simple and interchangeable components for which alternatives were easily available from sources other than Microsoft? Don't like services? Choose among half a dozen alternative background process management options, without affecting logging or file system layout, or listening to inbound network connections...
If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux.
If you use a computer for actual industrial work, you will hit one of these problems very quickly.
> there's tons of niche hardware that just can't be driven from Linux.
Linux developers can often do wonders, but they still do not have a crystal ball. If that hardware is niche+closed+expensive I don't see how they can produce working drivers or software. Manufacturers not releasing documentation are the problem, not Linux, or BSD or any other non supported OS.
Games are the most reliable category of software, the one WINE targets the hardest. Almost every software I try that isn't a game, fails to work in some way.
The worst offenders are "industry standard" software. 3ds Max. Ableton. Photoshop. Altium. MS Office. Visual Studio. Go check WineDB and see how many versions of these are rated "Garbage".
I say again - if you attempt to rely on WINE to do real industrial work on Linux using Windows tools, you are virtually guaranteed to hit a showstopper somewhere almost immediately. It's just not viable.
I'd argue the success of the Steam Deck is evidence of the Linux desktop's maturity. The normal game UI is just another Wayland session, and it's a fully functional PC running Arch Linux. KDE is installed and easily accessible.
I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show.
[0] and of course the efforts of the WINE project and proton.
There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc.
Having a lot of user mode stuff does tickle my fancy, being someone who is very keen on microkernels (despite windows being a hybrid), I can appreciste some of their design choices.
I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.
Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible?
> you should notify resolved of the domains that LXD can resolve
You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.
I think it's just someone unhappy that they used to be able to edit resolve.conf before systemd-resolved took it over. I recall being annoyed about it as well, but that was some time ago.
I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety.
What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable.
Or does it mean that Linux for overtake the market share of Windows and macOS. For that I would caution to be careful about what you wish for. Being an underdog brings an added benefit of having more flexibility and the option to think outside of the box. For Linux to overtake Windows it would slowly turn into Windows itself in my opinion.
> Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable.
Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.
- Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux).
- It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script.
- the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments.
- (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example.
Some arguments for systemd:
- systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent)
- systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective.
- systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop)
- systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system
==========
In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.
> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script
I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the provided “decrypt” tool and then further use the usual unix tools if you wish.
But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.
> But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.
From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me know if I'm wrong.
One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
>One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
> I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
I can grep my way through text logs as well but being able to get logs for different purposes using --flags is better user experience. I can always resort to to using grep, sed, and awk if I want to when using journald but the loss of these quality of life features make it hard for me to consider using a distro that does not have systemd.
It’s even more difficult to understand when you consider than text files are themselves binary logs and given how many encoding they can have they are not even trivial ones.
People should just call systemd logs structured rather than binary because that’s what they are. Sure it means you need a shim if you want to view them as plain text but it’s not like we are talking about some unfathomable complexity here.
And you don't need journald to read the log files either, you can use `journalctl --file /path/to/file.journal` to read them directly via `journalctl`.
I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important.
Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
There are solid technical reasons for systemd's binary logging.
The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones.
Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.
Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.
If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?
Just nitpicking, but AFAIK it's not journald which is used to read the logs, it's journalctl itself which directly reads the binary logs from the filesystem (and the normal filesystem ACL permissions are used to allow or deny reading the logs).
How do you do that? If you want non-binary logs, you can have journald tee log records to rsyslog; but the canonical log is still the binary log. Have I missed something?
Systemd will produce logs in its own structured representation and write them straight away as plain text in the logger of your choice. For all intent and purpose, you now have text logs.
What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
Every log ever is a transcodification of a system state. What difference does it actually make that it is emitted into systemd structured format before being put into your logger?
Seems like a pointless complain to me. It’s arguing for the sake of it.
That's not true, you can configure journald to be in-memory only in which case there's no binary log, no file. If your using systems, you can't really git rid of journald, but you can get rid of the binary logs.
It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.
Nohup is a disgusting hack from a previous century. I don’t see how having less information on what is happening to a process good — nohup interprets supposedly meaningful signals never meant for this misuse differently.
If you want to continue to run a process you have to start a service which is exactly that.
No, I don't have to do that at all, I can in fact use the standard unix way of making a process not terminate on SIGHUP by telling it to ignore SIGHUP.
SIGHUP is not a signal to shut down, it's a signal that says the controlling terminal is gone. The action taken by the process at that point is the decision of the process and the user that launched it, not the init system. This is exactly what it is for.
Changing that without understanding what people used it for across UNIX vendors for decades, was dumb. And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag.
It's not just random long-running batch jobs it killed either, it seems that it would kill all sorts of useful stuff people run for reliability. The irony of the init system killing screen/tmux sessions which people run specifically to keep their shell going in case of a disconnect!
>And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag.
Why do you assume they didn't know about this quite basic mechanism? They added 2 configuration options, one at compile time (to set the default) and another configurable by the user. In fact, distro maintainers didn't look up what it did and they just compiled it as is, resulting in the surprising behavior of killing lingering processes.
Also, it is an init and service management system and long-running processes are services. If you want to run something for "reliability" you should create a service for it, or just run the command with "systemd-run", to properly communicate with the responsible process manager what it supposed to do when the user logs out (and to actually make it reliable, e.g. you can then set it to auto-restart on failure, etc) Safely killing lingering processes and cleaning up after them is the correct default behavior, so systemd just tries to enforce that - they actually communicated with nohup maintainers to optionally add this systemd communication, so that "nohup whatever" would still work, but they were not open to it.
Even then, the default broke decades of standard behaviour so systemd failed users here.
> long-running processes are services.
Not all of them. A data processing/computation job running for tens or hundreds of hours is usually not a service. What is "long-running" anyway? Again, people used nohup for running their jobs for decades without being logged in. That is the standard usage of nohup, systemd broke it.
It might be the “correct” behaviour under systemd, it was not the correct behaviour under multiple other unix systems for decades, nor was it the expectation of Linux users or admins.
Paint it how you like, systemd broke decades-old, desirable behaviour for no good reason.
The attitude that everyone else is clearly wrong is unhelpful, and seems a red hat pathology. You see it with this and with Gnome, and it drives people away.
and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost.
systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.
Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
> The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
That was proposed to nohup when systemd introduced the modification. It’s what nohup does on macOS.
A very productive discussion was happening but then the anti-systemd mob showed up with pitchforks, brigaded the discussion on the bug tracker and made sure nothing good would come out of it.
That’s when I personally decided Linux was a lost cause and definitely switched to macOS.
> I personally decided Linux was a lost cause and definitely switched to macOS.
That is an strange course of action. So because you saw some low quality discussion on the internet, you switched from free software you can influence to commercial one you can't?
I don’t care about having this kind of influence. These are tools. I want the tools I use to be good so I buy good tools.
It’s not about low quality discussion. A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.
> I want the tools I use to be good so I buy good tools
Right, good strategy.
> A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.
Do you mean toxic users influence some developers to make bad decisions? Any examples? Toxic users dumping on systemd may be one, but I don't think they have that much impact, systemd seems pretty successful in not giving away. Anyway systemd is a very specific case, this is not representative of all linux software projects.
I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.
systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.
init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.
systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.
When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it?
Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
> the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years?
That is bound to be a losing strategy. Systemd development (of breaking changes) is not stopping anytime soon. The simplest solution is to switch to an OS without systemd, like Devuan or Alpine or BSD.
I mentioned systemd-logind. Its manual page systemd-logind(8) states¹: “See sd-login(3)² for information about the basic concepts of logind such as users, sessions and seats.”.
Systemd does a lot of good but they like to move fast and break things. Making tmpdir per process, their homedir changes etc are all good for security but tend to break things in unexpected ways
Today you still have this functionality as an unprivileged user via systemd --user units in .config. Unlike nohup you get proper logging and processes can even restart automatically on reboot if you want.
I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!"
It's usually a signal that the person is not a practioner.
Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.
I don't trust anyone's opinion, for or against, unless they've used alternatives. I've used systemd, I'll probably use it again, and I'll keep hating on it if someone gets me started. Fortunately on my own systems I've been a happy OpenRC user instead.
I've used both (OpenRC and systemd). I like the simplicity of OpenRC and still uses it on a few servers running on Gentoo, but on a laptop/desktop I think systemd is a better fit, having user services with user level logging for example.
Feigned certainty is often a indication of the opposite. In many cases people just absorb someone else's opinion on topics just in an effort to feel informed.
I'm not going to say I'm never guilty of it myself, but often asking even for the slightest bit of further explanation collapses that or otherwise just leads to repetition.
I mean have you actually used the alternatives? I find most of the people with that opinion are young pups who jumped on the linux train after most of the systemd bugs have been ironed out, but who still have zero experience with the alternatives.
I have used all the alternatives, and written my own init systems from 0.
Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly.
Systemd however is however not designed for server use, but neither is OpenRC or any of the alternatives. Servers filesystems should contain a kernel, a shim init binary, and a static binary for a target service.
When you want to upgrade your fleet you compile a new bundle of those three things into a new filesystem image and boot servers from the new image.
> Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly.
It sometimes randomly fails to boot, waiting for some strange condition, while I am not able to intervene via keyboard in any way. That is "well designed"?
I run Xorg as unprivileged user by executing startx, on sysvinit system. There is no problem that needs systemd solution here.
I mean it's pretty hard to debate the merits of systemd as a server init system when you think we should all be using come kind of containerization system :p
The Linux kernel is simply not designed to run trusted code and untrusted code at the same time. One service has a bug or a security flaw and everything goes down with it.
The sandboxing is a convoluted mess few even know where to start learning to use. Lets say you successfully configure process namespacing, network namespacing, filesystem namespacing, cgroups, and apparmor or selinux all correctly to restrict every last syscall. You will still get burned by a crash, resource exhaustion, or security breach due to the next of a long series of implementation bugs in each of these arcane features.
Humans cannot create a large codebase of coherent and provably correct C code with memory safety and they really should stop trying.
Hypervisors are the only sandbox that works reasonably well and burning some extra ram is cheaper than most security breaches.
On my laptop, systemd is awesome; I love it. Everything works together nicely.
On my servers, systemd gets in my way, tries to do too many things, and gets in my way more then it helps.
On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge compared to servers. An init system (plus all the extra plumbing) work well together.
On servers however; I HATE systemd. For logging, networking (and DNS) alone systemd wastes so much more of my time and gets in my way. I think the need for an 'improved' init system was always a red herring. I've never had a service race-condition, or other conflict that didn't take more then 10 minutes to fix in the 30 years I've managed *nix servers.
There was one time where I was stumped why my VPN server kept failing to start at boot but came up fine if I restarted manually. My dyslexic ass inverted the script number (ie. 13 instead of 31 or something like that). That was just a face-palm embarrassment.
Systemd should never be used on a server. Or any other desktop init system for that matter.
Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations.
A production filesystem should contain a kernel, an init binary, and either a container runtime or a static binary of your target application. At most a production init binary just needs to setup virtual filesystems and be a reaper for a target application binary.
> Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations.
That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice.
Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.
If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a distro that stands on its own, the fact it uses musl as its libc means you can't use it on a server that has nvidia gpus for machine learning, you can't use it on a desktop where you need a browser capable of DRM, you can't use it on a personal computer if you ever intend to install a video game etc.
I have -yet- to hear anyone in my life actually use something like Devuan, the systemd-less fork of Debian, in a production environment.
Six years after their first release, instead of standing on their own as a distribution, they're still deeply angry and obsessed with systemd and this is the level of professionalism they exhibit on social media :
https://twitter.com/DevuanOrg/status/1586963662295687169
Of course, one of the twitter comments underneath is "systemd macht frei".
I think that is an overstatement. I use systemd but there is legitimate criticism and even a questionable conflict of interest in the creator now working for the competition. People working against the best interest of the community is a real threat that shouldn't simply be ignored. However, so far systemd has worked out alright for me so I can't complain too much but the documentation is still lacking in certain areas and so doing things that are easy to understand with a traditional script based RC can become frustrating when you are trying to figure out the systemd-way to do things.
Microsoft hasn't been the competition for while. They might not be "part of the team", but they definitely have more to win by linux being alive than dead. I'd put them more along the lines of IBM or Oracle, huge corps trying to somewhat discreetly steer linux in a path that suits them.
Impressive. They have even a document that describes the problems with systemd. And not just any document, it's the most viewed research thesis of all time! Wow!
The Devuan founder is truly the most impressive person in the universe.
>Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year.
Void Linux doesn't use systemd because it doesn't build against musl libc. Void ships musl and glibc packages for multiple CPU architectures and has a very lively development team and update cycle. It's not dead, it's just not insanely huge, either.
It started with bad press because author made pulseaudio and its design didn't appeal to many (lots of features but missing pieces, not due to dev but market forces and drivers). So when the same guy says he's gonna rewrite pid1 with a radically different design people went ballistic.
My personal opinion is that proper dependency based init systems are amazing but I'm not fond of some slightly superficial aspect of systemd (syntax, parameters, logic, config files).. to the point I think in a few years someone may make a cleaner variant.
It’s not generally hated. It has a cadre of permacritics that are very vocal and often dramatic, and some of them often pop up in threads such as this one, that is all. It’s especially pathological since there are alternatives - if you hate Lennart, Redhat or whatever, use something else and move on.
Meanwhile millions are using it to get shit done without much drama. It’s been years since I filed a bug on systemd, but that’s what grown ups do when inevitable bugs are encountered, not make themselves and everyone miserable because they deeply integrated some dubious 1970s Unix philosophy into their personality.
A couple years ago, absolutely. To decide whether to generally hate systemd, and with what intensity, you should follow a curve that decreases proportionally with how long ago the change was made, and that starts as high as the multiplication of how much churn it causes times how old the thing it replaced was, all of which is of course multiplied again against the buggyness curve
When pipewire replaced pulse, despite pulse being well established and a core desktop component, there was very little churn and few bugs. People not impacted did not mind at all that a major component was changed, or that it did many things and bundled three completely different protocols into one, arguably not very reminiscent of Unix Philosophy™
I would confidently predict that a change as large as systemd, to a component as old, and that causes as much churn (rewriting, relearning) would follow a roughly similar hate curve, only distinguishing itself by whether it was more buggy or less buggy than the predecessor.
It's churn people hate, not change. The lesson I learned is that you can make large changes to the system, it's only hated when it forces humans changes.
It's worth remembering that much of the churn was caused not by having to rewrite configuration, but by the multitude of bugs that plagued systemd early on, and the way they were treated did not help. systemd upstream was extremely difficult to work with and made a lot of people reluctant to embrace change, because when something didn't work -- which we all understood was natural for software developed in the open -- you were pretty much screwed. Shell scripts and duct tape were bad but it could take less time to fix something than it took to get people "up there" to admit that they're really looking at a bug, not a feature.
I ran systemd very early on because it gave me some things I liked from SMF but I completely understand why so many people hated it. It's a (suite of) program(s) with good ideas that was hampered by extremely poor maintainership and relation with other open source projects.
Pipewire broke me lots of times during its development and rollout, and that's okay, because new software has bugs and in some of my other use cases "hey it's a lot better than Jack". What I'm not going to do is carry a grudge against the maintainer for decades?
I've been using Linux since Slackware installed from a pile of floppy disks. I'm extremely happy with systemd (desktop and server) and view it as one of the most important UX advancements ever made in the Linux sysadmin space. It replaced a smorgasbord of broken nonsense with a unified and thoughtful system that is objectively superior to what it replaced. I suspect a lot of the extreme reaction to systemd is not just resistance to change, but based on an emotional attachment to the rag-tag heterogeneity it made obsolete.
Hehe, I remember some people complaining about it. I never could hate SystemD once introduced to it as an infrastructure engineer. The difference was night and day in Debian (from wheezy to jessie).
Setting common sig handlers, restart on exit, etc. are just one-liners with unit files. In the previous one, SysV, it was an annoying incantation especially if you were a newbie, like me at the time, or product engineer who was dabbling. You could easily screw it up. Some non infra engineers cursed the SysV files and loved the SystemD unit files.
Now I use dynamic user and the other security features in my unit files and wonder how many lines it would have taken to do that in SysV, so the complaints are laughable at this point.
Less hated ad time goes on. I still think it's architecturally stupid (look at openrc for something that accomplishes similar goals but better), but it's been a while since it's broken anything terribly for me, or introduced any terrible security vulnerability. It's not great, but it's not actively hurting.
I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files.
I have trouble believing that people who loath it so much have actually sat down to read the documentation.
But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess.
Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers.
That's exactly what Alpine is, the OpenBSD of Linux distros. OpenBSD likewise cannot be used as your production powerhouse as well.
>never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora
Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland.
Bad argument, glibc and musl are not always compatible, and you can use that as argument against either. When it comes to standards, musl is actually the more conformant one.
The glibc 2.26 release with the ucontext breakages made me stick with musl.
Plus, when i did multiarch support in Alpine later, i found that LDSO paths for musl are much more systematically and don't have name collisions like glibc.
There are some very unfortunate ideological choice made by its author but they are not the one you quote. The reluctance to give developers a way to detect Musl from C code would be a better exemple. It’s both annoying and counterproductive.
> Without systemd, bootstrapping a complicated desktop environment would be a hot mess
What is a complicated desktop environment? Why should I run it? I want to run simple desktop environment, like Xfce. I run startx in tty, and get unprivileged Xorg with Xfce on sysvinit system. It's rock solid.
alpine linux is a minimalist distro intended for running a single process within a container. I guarantee the base OS the container is running on us running systemD.
No: "Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency."
who out there is using alpine as their daily driver desktop? the only time I've ever seen it used is as the base image for docker containers precisely because its so minimal (ie: lower attack surface area)
I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services.
I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.
What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?
In short it allows you to bundle your application in one file and have it run in a sandbox. Like a docker container, but without docker, managed by systemd.
User services are also a systemd thing; you can create systemd unit files (service descriptions) and have them run as a user. So as a user you can manage your own running processes using the same systemctl interface as system processes. If you are allowed to "linger" on a system, you can run user processes as a service, set them up and tear them down without root permissions.
I have several systems where I run i.e. webservices without having full root access. I build an portable systems image, deploy it to the server and then can manage that service with my unprivileged user account.
Systemd does all the usual things, like logging, supervision, resource quotas, and so on.
Right now my mom is nagging me to fix her Ubuntu laptop, which doesn't shutdown anymore because some of the units got messed up. I'm at the verge of telling her to install windows.
That is a really simple fix. Sounds like one of the units is hanging. This actually shouldn't prevent shutdown but may make it hang for like 2 minutes.
Is the project a new site sponsor or something? :-) I get it that systemd has some benefits - faster startup, more reliable production administration. And at the same time it's not everyone's cup of tea - for example, many believe that the strength of UNIX is many simple and interchangable commands rather than big monolithic code base controlled by a single team. Anyway, there have been 251 previous versions of systemd, so it's not clear to me why this one is special and deserving of our attention after another systemd related story yesterday?
> Anyway, there have been 251 previous versions of systemd
Trivia: when udev (which was at v182) was merged into the systemd project, they skipped from v44 to v183 to align the version numbers; so there have only been 112 previous versions of systemd.
Yes. Clicks on the voting arrows go to the HN backend, which routes them to systemd-votecount, which then generates article rankings and publishes them over D-Bus, from which the backend picks them up and renders them as HTML.
> it is definitely our intention to gently push the distributions in
the same direction so that they stop supporting deviating solutions ... -- Lennart Poettering - Red Hat, Inc.
Small detail, but interesting to see varlink capabilities added.
systemd-resolvd gains "monitor" capabilities via the lightweight json rpc system varlink.
definitely useful just for monitoring dns broadly, seeing whats happening on the system. there's probably some more specific creative uses folks could hack together here.
I'm enjoying dinit in artix. I think Artix is not terribly mainstream but the dinit part of it seems easy to deal with so far. It would be interesting to see it get polished in a different distro.
Living without systemd is sometimes a rough choice at the moment but I think it can be polished.
Take a look at Chimera Linux - https://chimera-linux.org/ . It's a desktop-focused distribution that uses dinit. It'll be one to watch once it stabilizes.
systemd is fine for single user systems and perhaps verts, but I would never deploy it on a server. The deprecation of cgroup v1 is a welcome change. It's come a long way, but it still has a very long way to go.
I imagine Facebook uses highly monitored virts that are spawned and destroyed constantly. I really wouldn't call them "servers" more like instances or staging hosts for containers. Root exploits aren't so serious in a ethereal state..
Facebook also uses PHP. The fact that somebody made a huge service work with a specific tool doesn't automatically imply it's the best tool, or even a good tool.
That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)
This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.)
The idea is you'd run batch jobs and services explicitly via systemd-run.
Security by default is usually a good default, yes.
systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place.
Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the standard systemd instead?
Security is a spectrum, and too much security means less freedom and shitty life experience.
I don't have a problem with a new tool such as systemd-run.
I do have a problem with breaking well established workflows in the name of security/efficiency/ideology, when users didn't ask for it. That is a policy question with different answers on different systems.
Anybody who cares about that kind of restrictions has to think and implement policies on their systems on their own. Relying on systemd to do the right policy thing for everybody is unrealistic, naive and warped idea of what users need.
You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc
About the logs, yes, plain text files, commands and pipes are great, but journalctl is really great too. It is powefull and includes everything you might need to inspect logs with accuracy in the same tool.
Just to clarify: I'm not a fanboy, I'm just pragmatic.
Surely the answer here is to add tools to the rescue system. You could make the same complaint with systems that use file systems not yet supported in rescue systems, such as zfs, btrfs, etc.
Why would you limit what can be done based on the current abilities of a rescue system?
So I think systemd is becoming a tentacle demon upon Linux but "registering a service" is not hell.
- You create a new whatever.service text file with some data=value pairs and put it in /etc/systemd/system. Doing this is at least only 25% as hard as learning bash.
