Installing Debian bookworm without systemd
diziet.dreamwidth.org
diziet.dreamwidth.org
init.d was familiar to graybeards (like myself), but I'm loathe to consider them a superior solution.
It forces you to think of stability instead of creativity, and that might be great for people who value predictable things in their lives, but it stands rigidly in the way of fun.
Technically, I guess it’s interesting to design if you are an expert but as a user, having to use creativity is the last thing I want from low level pieces of my OS. If you want to tinker with OS design, you can always install Minix in a VM.
I don't know about fun, but different people find different things fun.
I find systemd to be often irritating, and sometimes infuriating. It has not made my life easier at all. Just the opposite. So, in that sense anyway, I'd say systemd is much less fun.
Every distro did init scripts in different, exciting ways, so I had to start over from reading the not-inconsequential docs for each one. The init systems come with some high-level helpers, but only if you want to use the shell, which is very unfun in its own right.
I've been looking for these for years: the reasons that might justify the removal of basic functionality and interoperability with other tools. Got any sources?
From what I can see, the dislike exists for far more practical reasons.
In my experience, it has a tendency to break in ways that the numerous other init systems I've used over the decades never did.
When it does break, it can easily prevent a computer from booting, which makes that computer pretty much useless until the problem is fixed.
I've found that it has often been far more difficult, and takes far more effort, to debug and fix problems with it than with other init systems.
Its tendency to become more invasive over time has also opened the door for even more problems involving it, well beyond its role as an init system.
Given the large number of bug reports, questions, complaints, and so on about it that I've seen over the years, people don't dislike it just to be "fashionable". They dislike it because it's making their lives unnecessarily painful.
https://systemd.io/CONTAINER_INTERFACE/
You can argue that a process manager for an unprivileged container should be more like supervisor or systemd user services. However, it would be really convenient to be able to globally install unit files (say, using a deb package), and have them work whether it's bare metal, a VM, or a container.
"Operating Debian without systemd is a pleasure and every time one of my friends has some systemd-induced lossage I get to feel smug."
I guess I get that init was simple, but it didn't care about the process lifecycle. You always needed to have an incredibly smart init script or watchdog service to manage that.
This isn’t all systemd of course, it’s the distros that choose to use it.
Systemd replaces (or tries to replace) whole swaths of OS functionality all at once, instead of addressing each piece individually. As a result, all of the systemd pieces are tightly integrated and nigh-inseparable, and critics claim this was intentional so that distributions could not easily pick and choose the parts they wanted. My understanding is that this is better now. In my experience, some pieces are better than others. (Systemd-timesyncd is absolute rubbish compared to chrony, for example.)
Although the goal of writing a better init system is laudable, a lot of people who looked at it early on not impressed with the implementation (a lot of NIH wheel-reinventing) and mediocre code quality.
It was introduced into Fedora rather suddenly with seemingly little warning, community discussion, or press coverage. In the Linux world where big things change slowly if at all, other popular distributions seemed to adopt it fairly quickly, one after the other. This raised a lot of conspiracy-like speculation about how that could have possibly happened.
The developers are famously obstinate about their technical decisions and often argue in, close, or ignore bugs asking them to consider a different direction for specific low-level issues. There have been a few public disagreements over "correct behavior" when integrating with other projects (e.g. the Linux kernel).
It always encounters some service to hang to where systemd responds:
"Waiting for service to halt - xx / 2m"
I've never not encountered that experience.
This was the issue, I think: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742322
systemd hasn't been without issue, but I've definitely had fewer issues with systemd than I did dealing with broken init scripts or upstart prior to moving to systemd.
* System randomly taking 5+ minutes to boot
* Daemons sometimes not starting on boot
* Logging sometimes just stops (I confirmed this was caused by a systemd bug)
* Logging in over SSH starts taking 2 minutes and can only be fixed by reboot (I confirmed this was caused by a systemd bug)
It's not that sysvinit scripts are without bugs, especially race conditions and daemons inheriting environment when you invoke a restart script, but systemd appears to be distinct in that a seemingly-quiescent system can just suddenly stop working correctly. They had a low bar to clear to improve on the reliability of sysvinit systems, and yet they failed to clear it. That's not surprising given its excessively complex design.
I can't say that about any of the other init systems you just mentioned.
> They had a low bar to clear to improve on the reliability of sysvinit systems, and yet they failed to clear it
systemd hasn't just cleared it, it has leapfrogged it.
* System randomly taking 5+ minutes to boot
"systemd-analyze blame" can help identify issues relating to boot time
* Daemons sometimes not starting on boot
This most often occurs for me when services don't start quickly enough (too much contention on spinning rust and aggressive default timeout settings) so I have to adjust startup timeouts. "systemctl --state=failed" along with "systemctl status X" can usually help narrow down why your services failed to start.
* Logging sometimes just stops (I confirmed this was caused by a systemd bug)
I've found journald can get forcibly restarted if there is a lot of contention for disk iops and it can't checkpoint. I frequently run into this issue on a server that is used for backups for about a dozen or so clients that relies on filesystem snapshots.
* Logging in over SSH starts taking 2 minutes and can only be fixed by reboot (I confirmed this was caused by a systemd bug)
I've sometimes had this happen and for me it seems to be related to systemd-resolved deciding to stop responding to queries and the only solution I've found so far that actually works is to restart the system.
Despite the bugs I still prefer systemd over sysv-init - being able to run something like "systemctl status" and "systemctl --state=failed" to inspect the state of all services on a system has been invaluable to me.
I hit this all the time on my Arch laptop and was a major impetus to switch to Void.
I use Void, btw.
"Lossage" means "the consequences of a lose" even if no data loss occurs. Some people consider systemd with its complexity and tightly coupled components to be a lose.
I used Debian without systemd for a long time until it was no longer possible by upgrading. (I believe they make an effort to optionally run without systemd nowadays). In the meantime systemd got better. I still don't like it. It's like how people won't give btrfs another chance because it ate their data once 15 years ago. I think this is completely understandable. Thinking about the past, looking at the history, there's no reason to trust neither the technical skills or ethics of the people pushing systemd (or snaps) either.
can you name those? I am eager to try them in system with minimum resources.
Systemd does not appear to be able to tell when that happens. It thinks the network is established before it actually is, and then the mount calls cause the startup process to pause for 3 minutes for those mount calls to time out before continuing.
https://github.com/systemd/systemd/issues/25269
I'm still livid at this Luca guy gaslighting people on the "correct" behavior of a feature people were using for years already. They re-purposed an existing sleep mode and changed it entirely to mean something else. Originally you would set a timeout that your laptop would suspend and then hibernate. They changed it to mean that your laptop suspends until your battery hits 5% and then hibernates. As if people want to open their laptop the next morning only to have no battery left.
Ironically, the stated reason for this change was to "prevent data loss". Guess what they did? They introduced a bug in this "fix" that guaranteed your laptop would not wake from hibernate. You had to reboot the damn laptop each time you woke from hibernate because it would get stuck on a black screen, thus "losing" your data. I "lost" more data from their stupid fix than anything else.
They admit the original feature was broken because it didn't take into consideration for battery percent. Fine. But there was absolutely no reason to change the behavior. You can do both! The only reason I can think of is you just like being an incredible asshole to people. Which is obvious from that thread. Do they even use a laptop? Why would I want a dead battery next time I open the lid???
As a fellow (though not lately very active there) systemd maintainer, reading his comments in that issue is a real bummer.
I'm not sure I'd call it "gaslighting", I don't think he was even bothering to grok what people were asking for. Not until it became a pile-on of additional systemd members @yuwata and @DaanDeMeyer.
Maybe he's checked out a bit with all the drama going on over at BlueHat?
Also, it has 1.2 million lines of code. It's massive for an init system. It increases the chance of potential bugs which can be exploited.
You're willfully conflating the systemd project repository with the init system.
I use systemd the init system, but in-tree components like resolved and networkd have never run on any of my machines.
Surely you can understand that a monorepo with code reuse across myriad components has its advantages, and that systemd the init system can be just a subset of that tree.
One can argue the systemd project is simply following in the Linux kernel's footsteps here. It too is a monorepo chock full of all kernel functionality one might ever need, with the expectation that use cases will pick and choose what snowflake suits them best.
Linux is openly a monolithic kernel that builds everything in one tree. Are you sure that's the analogy you want to pick?
And most of the other components only work with the init system; systemd is modular, but it's one system.
> Almost all of the components are optional and many of them integrate through well-defined interfaces.
Well-defined interfaces that the project specified themselves and that rarely have any other implementations.
I would love if a major distro emerges which works with human-readable scripts and logs and stays away from any "binary" formats for system configuration and logging.
Good news for you! You have slackware [0], void [1] and alpine [3], which are widely-used non-systemd distributions with sane scripts. They are well-maintained rolling releases which allow you to use much newer versions of the kernel and packages than your typical ubuntu/debian installs. I don't particularly care about systemd, but these distros are great by themselves!
I do highly recommend it though! Slackware's init scripts were always a pleasure to use, part of why I was anti-systemd for a long time.
My only real headache with FreeBSD has been SAMBA. It seems that every major upgrade bjorked the SAMBA user/account DB, and would cause much wailing and gnashing of teeth. So I learned to deal with that.
I now work for a K8s shop, and find myself migrating back into the linux/systemd fold. There's frustration with systemd'isms, and I truly despise the binary logs; but I'm learning.
But what I found was lots of hate and stupid talkin against systemd, that they all hate it and that FreeBSD will "never have this $hit"
I thought to myself, yeah just hate systemd but not able to produce an easy to use and full fledged service manager. The arrogance was staggering, and I stopped my use of freebsd since then, in almost all aspects linux is superior anyhow.
Such a fully featured systemd service is easily done in 6 - 8 lines of configuration.
Alpine is probably your best bet, it's pretty widely used. All of the others are a minority of a minority of a minority.
isn't a text file also binary at the end of the day?
They more easily work with a lot of un-specialized tools, or tools specialized for text, which is a very general problem with very transferable learning.
Perhaps better to distinguish between "structured" and "unstructured" or "machine optimized" vs "human optimized".
A different beast at the end of the day, whatever name or distinction you use.
They also have a pretty good page on their wiki that explains the current popular alternative init systems to systemd(0), even ones gentoo doesn't support.
Actually, I don't really care about the init system, as far as I can tell. When I started using Gentoo, the default was OpenRC, so that is all I have ever known.
I have not the faintest idea what benefit I would get from using Systemd compared to OpenRC, so I have never tried changing. I have used Debian with Systemd, and I can't particularly tell the difference from an everyday-user perspective. I used Ubuntu a few times when I think it had upstart maybe? Again, no idea what the difference is.
All I know is that there are things I can do with the rest of Gentoo that I have not easily been able to do with other distros, so that is where I stay.
Anyway, for anyone who hates systemd for whatever reason, Gentoo is definitely an alternative. It is a little weird to me that any distro would have a hard dependency on a particular init system, when it is clearly not necessary. More work to be compatible with multiple, I guess? At the same time, I don't really understand the hate. Just ... use something else?
I get the silliness of journald not being clear text, you can configure it to be, but it's not the default, which is really weird. If you have the scale where you need binary logs for performance, then you also have remote log hosts. The remote log hosts will frequently also store logs in a binary format, like logstash, Humio, Splunk and what have you, but they are shipped a text, so the binary is just an unnecessary extra step. Sure you can use journald as a log collector, but I've never seen anyone do that... Kinda cool, but not frequently used.
Systemd unit files though, those are much much better than any other init system I've ever used. They are easy to write, easy to understand and just overall nice to work with. Timers are awesome as well, same easy syntax as startup scripts, easy to test, easy to debug.
If anything, the presence of Devuan cements systemd even more tightly into position -- those who care about not running systemd are distracted by forking an entire distribution, rather than putting their effort into the much smaller problem space that is retaining functionality that Debian is quite happy to retain if its proponents are willing to put in the effort.
So Debian is going to integrate more with systemd than it would if Devuan didn't exist, and I suppose for that I should thank the folk behind Devuan. But it's always disappointing when people expend their effort against something, rather than for something.
Very happy Debian and systemd user here, in case you couldn't tell.
There's obviously more to this (and to Devuan) than just uninstalling systemd and installing sysvinit. Devuan's package repo (for which Debian is the upstream) contains a lot of customizations to allow certain packages to function with a sysvinit foundation.
Ultimately though it's entirely up to the developers where they put their effort. If folk prefer to work on a fork, they're entitled to do that. And it is a bit refreshing to see people putting at least some effort into not-systemd, rather than complaining about being "forced" to use it.
And Debian says they’re fine having non systemd but any work needed to make openrc etc viable falls on the these guys.
https://distrowatch.com/search.php#advanced
Note that under the "Init Software" section (scroll down on page!), the following two choices (amongst numerous others, perhaps too many!) are included:
[ ] systemd
[ ] Not systemd
In other words, here, the User, regardless of their opinion, regardless of their political ideology (or lack thereof!) -- has a happy choice!
They can choose whatever they themselves believe to be the correct choice in the matter!
Or they can choose to leave both checkmarks blank -- and let Distrowatch's Advanced Search -- decide for them, and perhaps "surprise" them! :-)
You know, like you like Coke, I like Pepsi...
You like Windows, I like Linux (or vice versa!)...
You might think that it's a floor wax, I might think that it's a dessert topping -- but we could both be right!
Ah, choice -- it's a beautiful thing! <g>
"Init Freedom is about restoring a sane approach to PID1 that respects portability, diversity and freedom of choice."
Stuck at Lilo.
"Not found".
Standard Dell Optiplex 790.
Time to breakout the Debian Rescue DVD.
(sigh)