Debian Project Drafts General Resolution on Init-System Diversity (lwn.net) 212
Debian "is heading toward a new general resolution to decide at what level init systems other than systemd should be supported," reports LWN.net.
"I'm absolutely convinced we've reached a point where in order to respect the people trying to get work done, we need to figure out where we are as a project," writes Debian project leader Sam Hartman. "We can either decide that this is work we want to facilitate, or work that we as a project decide is not important."
LWN.net reports: The immediate motivation for a reconsideration would appear to be the proposed addition of elogind, a standalone fork of the systemd-logind daemon, to Debian. Elogind would provide support for systemd's D-Bus-based login mechanism -- needed to support small projects like the GNOME desktop -- without the need for systemd itself. The addition of elogind has been controversial; it is a difficult package to integrate for a number of reasons. Much of the discussion has evidently been carried out away from the mailing lists, but some context on the problem can be found in this bug report. In short: merging elogind appears to be complex enough that it would be hard to justify in the absence of a strong commitment to the support of non-systemd init systems. It seems possible that this commitment no longer exists across the distribution as a whole; the purpose of a general resolution would be to determine whether that is the case or not.
Unsurprisingly, Debian developers have a variety of opinions on this issue. This response from Russ Allbery is worth reading in its entirety. He argues that the 2014 decision (of which he was a part) never really nailed down the project's position toward other init systems. That was a necessary compromise at the time, he said, but it is causing stress now: "while I feel somewhat vindicated by the fact that this didn't immediately fall apart and has sort of worked, I think it's becoming increasingly untenable".... Josh Triplett zeroed in on one of the issues that is testing the init-system peace now. There is, he said, an increasingly long list of features that are only available with systemd, and application developers want to use those features... The responses to this argument took a couple of different approaches. Ted Ts'o described those features as "the 'embrace, extend, and extinguish' phenomenon of systemd which caused so much fear and loathing."
There's much more information in LWN.net's 1,600-word article -- but where do things stand now? Hartman posted a draft general resolution last week with three choices.
"I'm absolutely convinced we've reached a point where in order to respect the people trying to get work done, we need to figure out where we are as a project," writes Debian project leader Sam Hartman. "We can either decide that this is work we want to facilitate, or work that we as a project decide is not important."
LWN.net reports: The immediate motivation for a reconsideration would appear to be the proposed addition of elogind, a standalone fork of the systemd-logind daemon, to Debian. Elogind would provide support for systemd's D-Bus-based login mechanism -- needed to support small projects like the GNOME desktop -- without the need for systemd itself. The addition of elogind has been controversial; it is a difficult package to integrate for a number of reasons. Much of the discussion has evidently been carried out away from the mailing lists, but some context on the problem can be found in this bug report. In short: merging elogind appears to be complex enough that it would be hard to justify in the absence of a strong commitment to the support of non-systemd init systems. It seems possible that this commitment no longer exists across the distribution as a whole; the purpose of a general resolution would be to determine whether that is the case or not.
Unsurprisingly, Debian developers have a variety of opinions on this issue. This response from Russ Allbery is worth reading in its entirety. He argues that the 2014 decision (of which he was a part) never really nailed down the project's position toward other init systems. That was a necessary compromise at the time, he said, but it is causing stress now: "while I feel somewhat vindicated by the fact that this didn't immediately fall apart and has sort of worked, I think it's becoming increasingly untenable".... Josh Triplett zeroed in on one of the issues that is testing the init-system peace now. There is, he said, an increasingly long list of features that are only available with systemd, and application developers want to use those features... The responses to this argument took a couple of different approaches. Ted Ts'o described those features as "the 'embrace, extend, and extinguish' phenomenon of systemd which caused so much fear and loathing."
There's much more information in LWN.net's 1,600-word article -- but where do things stand now? Hartman posted a draft general resolution last week with three choices.
- Affirm init diversity
- Support "exploring" alternatives to systemd, "but believing sysvinit is a distraction in achieving that." [Marco d'Itri later noted that less than 1% of new installs use sysvinit]
- "Systemd without diversity as a priority." There would be no requirement to support anything but systemd in Debian.
"It should be noted, though, that this is explicitly a draft," concludes LWN.net. "It is likely to evolve considerably before it reaches the point where the project will vote on it."
I'd rather ditch GNOME (Score:5, Interesting)
I'd rather ditch GNOME if that's what's making it hard to implement another init system. If they can't be arsed to support normal Unix login, they can take a hike.
Re: I'd rather ditch GNOME (Score:5, Insightful)
My thoughts exactly. Why does a UI need to depend on SystemD?
Re: I'd rather ditch GNOME (Score:5, Informative)
Gnome depends on X windows, which depends on a stable network,
Connections to local displays do not go through the TCP stack. If only you knew what a Unix socket was.
Re: (Score:2)
I implemented IPSEC on an HP-UX system and discovered that the examples in the documentation were backwards. HP is a bad joke.
Re: (Score:2)
Re: (Score:2, Interesting)
If they can't be arsed to support normal Unix login, they can take a hike.
If normal Unix login can't support the kernel features which were implemented many years ago, maybe it should be the one hiking. Or better still, why not embrace that wonderful diversity Linux has to offer and actually use a distribution that meets *your* use case.
Re:I'd rather ditch GNOME (Score:5, Insightful)
Unfortunately systemd has become the standard. I have a strong dislike of it but that does not change anything.
Neither does bending over and taking it.
The existence of Devuan proves that there is a user base which rejects systemd. The existence of this story proves that there is interest within Debian in accommodating such users.
Re: (Score:2, Interesting)
Neither does bending over and taking it. The existence of Devuan proves that there is a user base which rejects systemd.
The relative popularity of Devuan vs systemd and the similarities between the distribution proves that very few people are "bending over and taking it" as much as they are receiving it with open arms.
The existence of this story proves that there is interest within Debian in accommodating such users.
Really? Because it seems like this story is about determine if Debian can conclusively tell those users to sod off. This isn't a story of accommodation, this is a very much an open discussion which has been called for by a vocal minority and a discussion that very much has not yet reached a conclusion.
Step in the right direction (Score:2, Interesting)
This is a step in the right direction (since the previous stance was "Fuck you. Use Systemd"). However, I fear too many people are simply indifferent to the desires of other for this to get any real traction.
Re: (Score:2)
This is a step in the right direction (since the previous stance was "Fuck you. Use Systemd"). However, I fear too many people are simply indifferent to the desires of other for this to get any real traction.
Given the direction that Debian has taken with systemd, I would be shocked if the result is anything but making the "fuck you, use systemd" stance official.
Re: (Score:2)
That's what I think is going to happen.
Re:Step in the right direction (Score:5, Interesting)
I suspect you are mistaken, this reeks strongly of a desire to formalize that exact previous stance so they can once and for all toss out any heretics who dare question the systemd gods. Right now they have no official policy, so some people still manage to question systemd. That won't do, and they're determined to fix that.
Say what you will about Systemd, but it has political connections like no other project short of the kernel itself (and possibly even better than those!)
Re: (Score:2)
Say what you will about Systemd, but it has political connections like no other project short of the kernel itself (and possibly even better than those!)
systemd has profit motives these days. IBM make money selling their services to their customers to fix the stuff they broke. (See also DOORS, ClearCase, DOORS NG, Jazz SCM).
If everything worked perfectly you couldn't sell "systemd" experts to clients that are locked in to RedHat. (And no, just because it's FOSS doesn't mean that clients aren't locked in without substantial cost that management will never pay for).
gentoo (Score:2, Interesting)
has maintained openrc along side systemd from the beginning.
A lot fewer headaches when you don't jump in with both feet and abandon previously-working solutions only to decide later that you want to go back to them...
Re: (Score:2)
has maintained openrc along side systemd from the beginning.
Now if only I didn't have to build the system with no USE flags, and then build it again with one USE flag, and then build it again with two USE flags... Even setting just five or six of them at install time causes the build to fail.
What is systemd ? (Score:2)
‘Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server? A system logger? Something that uses QR codes?’ ref [freedesktop.org]
“The singular aim of systemd is to get other projects to depend on it. T
Re: (Score:2)
Yep Init. Just Init. Exclusively init. the systemd package is the init system.
Then why is it so big? It must be bloated if that's the only thing it's doing.
Re: (Score:3)
It's so big because the systemd developers have taken on supporting lots of stuff that's not part of the init system.
Re: What is systemd ? (Score:2)
"Then why is it so big?"
All those backdoors take up space.
Just throwing this out there ... (Score:2)
Systemd user sessions, socket activation, sysusers, dynamic users, systemd-homed, temporary directory setup, transient units, anything talking to the slice or control group APIs, containerization, firstboot, systemd's whole "preset" system-wide configuration and policy mechanism for admins to say "what services do I want launched when installed and what services do I want to leave stopped until I configure them", "stateless system" capabilities, and I'm probably forgetting another dozen.
I think we need to move past the framing of "people don't want to write init scripts"; this is also about being unable to use a decade of additional capabilities that go far beyond sysvinit.
Granted, some of those things are appropriate for an init system role, but doesn't systems also have some support for things like DNS, NFS and NTP? Feel free to add other things systemd does that it really doesn't need to (shouldn't?) be doing.]
In any case, maybe systemd is doing too much, after all, it's suppose to be an init system, not the general OS toolbox. Perhaps I'm preaching to the choir, but just adding my $0.02.
Re: (Score:2)
No.
Here's a cracker, Polly
We resisted when Microsoft embraced and extended (Score:2)
Just build standards (Score:3)
The best way to deal with this is to build bona fide standards -- APIs, wire protocols and such-like -- for all the features that systemd is trying to expand into. Do this for anything where the "de facto" way of doing it is really poor for various reasons, and a new design is needed to simplify and clean up the system. Introduce these userland standards at places like the Linux Plumbers Conference, and invite other implementations than systemd to pick them up. Specifically design the standards so individual pieces of the stack can be slotted in, rather than requiring by design that the entire thing be a monolithic project/daemon.
Once you accomplish that, it would be easy for application developers to target these APIs and wire protocols in a way that's easily swappable between systemd and other implementations, and users could either use systemd or alternative implementations of any subset of the features.
This would require a slight change in direction from systemd, towards more of a standards-based implementation and perhaps slow down the velocity, but it would make it much easier for folks to support new features -- things that the old standards like POSIX, X11-related standards couldn't support -- without having to track an arbitrarily-changing systemd design. Then, it would be easy for projects like Debian to decide to support init system diversity as long as they can implement these standards, and systemd would no longer be the only way to get these features. In turn, downstream projects like GNOME would target the standards instead of targeting systemd directly.
There's value to be had in making a standard so general that you basically HAVE to have multiple implementations of it before it gets standardized. That's how the web works -- with a few exceptions like proprietary codecs, by and large the web standards work pretty efficiently at introducing new JavaScript versions and suchlike, but you almost never see websites these days "designed only for Chrome" or something. You can use the latest Firefox, Safari, or Edge to get the same functionality. Sadly, Edge is going away -- I liked it in the sense that it increased browser engine diversity -- but at least there are still the big three.
Having multiple implementations of the standards all but prevents private extensions and arbitrary incompatible changes, because users will complain if a significant market share belongs to a competing product and they can't take advantage of what your site demands. We could do something analogous with the login, networking, logging, hardware management and init systems built on top of Linux, with systemd being kind of the Firefox (the grandfather) and something else being the Chrome (the newcomer).
Debian? What's that. You mean Devuan? (Score:3)
Don't waste your time (Score:3)
I can save you a lot of time. If you feel the need to discuss whether or not you want to support diversity then the answer is clearly no.
There are only two meaningful answers to a question like this: yes or no.
If your answer is yes then it won't change anything. A discussion like this can only occur after support for diversity has already been lost. People will not change their opinion because you release a press statement. Trust is regained through action.
If your answer is no then it will not change anything because you have already stopped supporting diversity. The only effect is to act as a psychological barrier to any future attempts to support diversity.
Given the outcomes above there is no reason for anyone who supports diversity to want to have a discussion about diversity. At best there will be no effect. At worst, the opportunity for institutional change will be lost forever. On the other hand, if you are against diversity then these outcomes are very good for you.
My advice is to abandon this high-level discussion and return to the concrete problem. Do you want to merge this package or not?
Re:Debian user here (Score:5, Insightful)
Systemd has always worked reliably for me.
You are in the minority, then. Although I'm a RedHat guy, I've heard plenty of horror stories from the low-level Debian integration that's been done.
On the RedHat side (meaning RHEL7+ and Fedora in the 15-23 range), integration of systemd and all of the changes required (or "required") to enact systemd has been one long lesson in instability, backwards compatibility breaks, and a billion other points of pain in the name of "progress". Everything from private tmp debugging, logging (or lack thereof), verbosity, binary tooling, boot hangs up the yin-yang, and multiple levels of interface renaming "because it's good for you to not have an eth0 on single-interface VMs."
All to enact something that has few necessary features that weren't already being solved by sysvinit+service-manager-of-choice.
I went through this same drama with SMF on Solaris. You remember that?
Yes, I do. But Linux is not Solaris. And Linux is not OS X either, which is intended for unified graphical control over the fundamentals over the operating system.
In Linux, there's a long history of the ability to administrate the system using scripting and admin-level customization and tooling. When you replace perfectly-functional deterministic, imperative scripts with buggy binaries making assumptions based on declarative configs, you take that control away. And it reveals the degree to which Linux is used in ways outside of the Freedesktop.org, GNOME, and systemd cabal's conceptualization.
Not all of us have, as our first architectural priority, boot speed and interface re-configuration on our laptops when we're at the local Starbucks.
Re:Debian user here (Score:5, Insightful)
Amen.
I'm getting old, I guess, but the systemd way has largely served to complicate things I learned 20 years ago. The faster boot times are nice, I guess, but I don't use Linux as a personal computer. I use it for servers, which should hopefully only require booting on the same schedule that Wu Tang Clan uses to releases albums. I simply don't get systemd.
If it dramatically improved the kinds of things I require from a server, well I'm all ears. But I don't see it. I have no desire to plumb the depths of systemd's colon to figure out why my server crapped the bed. Not when the old ways worked just fine.
In 5-10 years, maybe systemd will be so slick that it'll be dumb to do things any other way, at least for workstations and laptops. Servers are different.
Re: (Score:2)
Re: (Score:2)
And Linux is not OS X either, which is intended for unified graphical control over the fundamentals over the operating system.
Been using RHEL Workstation at work since 5x days, now on 7.7. I fear that is the direction RHEL is moving in. When I went to 7.7 I tried to fire up my preferred WM (fluxbox) at work, and it has a lot of screen display issues. Prior to 7.7 FB worked fine. Between that and RHEL announcement I remember seeing about KDE, seems it will soon be GNOME3 or the highway
At home I use Slackware as a server and desktop, it is about as exact opposite of RHEL as one can get, and have not had any issues with it in wel
Re: (Score:2)
Systemd has always worked reliably for me.
You are in the minority, then.
My "favorite" systemd fail is the infamous "Reached target shutdown" on CentOS 7 when you try to reboot a server. Because everyone loves a server that hangs on reboot. Ubuntu used to do this as well, but I believe they pushed a patch out sooner.
Re: (Score:2)
I doubt he's in the minority. When I admined a ton of RHEL7 servers I also had no problems with systemd. Also at the time I was on the RHEL7 mailing lists and there was very little said about widespread issues. There were and are definitely bugs. But not the widespread show stoppers that seem to be suggested here.
Your negative experiences are just as anecdotal as my positive ones.
Deterministic and perfectly functional? Haha. That's rich. Init scripts were not perfectly functional and they certainly wer
Re:Debian user here (Score:5, Insightful)
Don't forget the bug where any user that started with a numeral got root access:
https://github.com/systemd/sys... [github.com]
Pottering immediately showed he had zero understanding of history:
Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names.
IIRC I tested it on numerous platforms and RedHat was the only one that didn't allow "0day", including FreeBSD and Solaris.
I don't know who thought it was a good idea to let the guy that wrote PulseAudio write an init system before PA itself worked*.
Now that RedHat is owned by IBM I don't see anything good coming out of it anytime soon. I say this as a victim of ClearCase, DOORS [ibm.com], DOORS NG and the "Jazz Suite [jazz.net]". IBM is where products get bought to get milked to their death while marketing shoves it down customers throats.
* My favourite PulseAudio "feature" was when I saw that my laptop was dumping a constant stream of the audio to multicast which is why my internet appeared slow.
Re: (Score:2)
Not all of us have, as our first architectural priority, boot speed and interface re-configuration on our laptops when we're at the local Starbucks.
To be honest, I don't know what Red Hat's priorities are but I'm pretty sure it's not laptop service and support revenue and they're throwing money and resources after systemd. I'm guessing somebody - maybe large cloud/virtualization customers - like it?
Re: (Score:2)
Not all of us have, as our first architectural priority, boot speed and interface re-configuration on our laptops when we're at the local Starbucks.
To be honest, I don't know what Red Hat's priorities are but I'm pretty sure it's not laptop service and support revenue and they're throwing money and resources after systemd. I'm guessing somebody - maybe large cloud/virtualization customers - like it?
You realize systemd is designed for single user graphical systems, don't you? That many of the design decisions show that they don't even look at multiuser, non-GUI systems. And remember how Pottering argued with Linus on who owns the boot parameters?
Re: (Score:2)
I remember Linus conceding that userspace was right to honour all boot parameters, as long as they didn't flood the logs with spurious asserts, the real bug.
I see we have another parrot here.
Re: (Score:2)
If you haven't got the time/inclination, this is from the "myths" article
3. Myth: systemd's fast boot-up is irrelevant for servers.
That is just completely not true. Many administrators actually are keen on reduced downtimes during maintenance windows. In High Availability setups it's kinda nice if the failed machine comes back up really fast. In cloud setups with a large number of VMs or containers the price of slow
Re: (Score:2, Insightful)
You are in the minority, then.
[Citation Required] Linux, specifically systemd based installs are being used over the entire bloody world. If what you said were true then mailing lists would be absolutely dominated almost elusively by systemd related problems, or you would have to admit that nothing in Linux works for the majority and it's a problem OS in general (it's not).
All to enact something that has few necessary features that weren't already being solved by sysvinit+service-manager-of-choice.
But then we clearly have just seen that you have no idea on the feature set that systemd provides nor why it was being adopted. Case in point, up until elogind there
Re:Debian user here (Score:5, Insightful)
Re: (Score:2)
SystemD seems to me to be an effort to smooth out some of the sharp edges that require technical sophisti
Re: (Score:2)
First, you are free to use sysv-init scripts with systemd.
I strongly suggest that you do not do this. You will regret it as systemd fails hard when things are started outside of it's control in that way.
Re: (Score:2)
One of the core principles of systemd has always been compatibility with sysv init scripts. So actually it does work fine. In fact systemd will happily defer to the init script if it can't find a systemd unit for the service you're asking for. Back when debian was transitioning to systemd there was a time when 90% of the services were init scripts and very little was done with systemd unit files. And it worked together nicely. Sure you don't get process supervision this way, or the fine-grained dependenc
Re:Debian user here (Score:5, Informative)
One of the core principles of systemd has always been compatibility with sysv init scripts. So actually it does work fine. In fact systemd will happily defer to the init script if it can't find a systemd unit for the service you're asking for.
Hardly. sysv-init scripts are entirely relegated to second-class (as was the intent all along). In fact, they're not even handled directly in the core any more, but via a shim... and this is deemed a feature.
Re: (Score:2)
What possible difference does it make how init script support is implemented?
If you are a glutton for punishment, you're free to write init scripts and they "work" as they used to.
Re: (Score:3)
It's always nice if a clueless luser gives themselves away. That's not a systemd issue, and if you were anything but a barely competent script kiddie, you would have known that.
And with that massive blunder, it is obvious what the rest of your imitation of a parrot is worth: Zilch.
Is that you, Lennart?
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ [freedesktop.org]
Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before they can invoke commands on it where previously they had a good chance that "eth0" was the right name.
Re: (Score:2)
| Is that you, Lennart?
| https://www.freedesktop.org/wi... [freedesktop.org]
That's really udevd, one of the many daemons that is managed by systemd.
I think Lennart and company first revamped the init system then they turned their attention to the many services the init system manages. They really shouldn't be attaching the systemd moniker to all this stuff, it's giving the wrong impression. The systemd init system is rather small. It's all the services they're revamping that creates the huge source file.
Re: (Score:2)
Re: (Score:2)
Systemd has always worked reliably for me. I went through this same drama with SMF on Solaris. You remember that?
I remember that everyone hated SMF, and I know that nobody runs Solaris by choice any more. Linux clusters ate its lunch for everything but running Oracle servers, and if it weren't for Oracle licensing, it would probably dominate there too. I don't think that's all SMF's fault, but it couldn't have helped.
Re: (Score:2)
Yeah, there is lots of shit in that box (Score:5, Insightful)
> none of them offer a feature set comparable with that of systemd
And if we add a web browser to it, that'll be another feature other init implementations don't have. Maybe a Tetris game - the other init implementations don't have Tetris built-in.
Perhaps because the other init systems do - init. They start the system services. Because that's ya know, the job of init.
Maybe Tetris could be a separate thing, not part of the boot sector or init. Maybe there is a reason volume snapshots are handled by the volume manager. Maybe other methods of starting system daemons don't handle
There is one significant problem with sysvinit - scripts run synchronously, in order. For some applications, you'd like daemons to start in parallel. That's the problem that needed to be solved. Upstart solved it.
Re: (Score:2)
insserv and startpar also solved it for traditional initscripts.
Re: (Score:2)
That makes sense (Score:5, Insightful)
Since the purpose of of init is to start services/processss on boot, it seems like it would make sense for init to monitor those processes and restart them if the screw up.
Until you think it through. 99% of the time if your web site is down, it's not because the httpd root PID no longer exists. It's because the drive is full or the database server can't be reached or you upgraded PHP and some code broke or any of 1,000 other things. Checking that the parent PID exists isn't what you need. You need to use something like Monit to check that the web site is up, that the mail server is delivering mail, etc. Those are very application specific things, it's not PID or process management.
A quick Google shows that one of the main questions people have about monitoring services and systemd is how to get Monit or another system designed for monitoring these applications to work again after systemd screws up the monitoring.
Heck, SysVInit could watch a pid, so if you really find that valuable (because you don't have any monitoring for your web site?), you could do that with SysVInit too.
> Let's not turn every discussion into a joke. When I talk about the useful features of systemd,
I apologise, but when you start talking about how many different features systemd has, it's hard to discuss that without systemd sounding like a joke. It's like discussing how Trump has elevated the office of president and made it an inspiration to the nation again - how do you respond to that in a way that doesn't come across as ridicule? In my view, systemd is a clown when it comes to adding more and more shit, so it's difficult to discuss that without pointing out the big red nose.
Re: (Score:2)
Since the purpose of of init is to start services/processss on boot, it seems like it would make sense for init to monitor those processes and restart them if the screw up. Until you think it through. 99% of the time if your web site is down, it's not because the httpd root PID no longer exists... Those are very application specific things, it's not PID or process management.
You said that better than I could, and it is worth repeating. System monitoring isn't generalizable.
Re: (Score:2)
When I absolutely need something to run on my FreeBSD machines I use daemontools [wikipedia.org].
The last stable release was July 2001, because it's not needed another release.
So even when FreeBSD's rc.d fails to keep a process running (Edge cases) daemon tools *just works*.
Good ol DJB (Score:2)
Daniel always has something that's quality, and completely different from what it replaces, doesn't he.
Re: (Score:2)
"If a mathemetician/cryptographer wrote everyday software". Imagine if you could talk him into doing the MAX8 software.
I wonder if you could use svscan as pid1 and let it do its thing:
svscan is designed to run forever.
Re: (Score:2)
Re: (Score:2)
Let's not turn every discussion into a joke. When I talk about the useful features of systemd, I'm not thinking about Tetris; I'm thinking, for instance, of proper service monitoring.
Help me understand why the fuck is a firewall built in to systemd...
Re: Yeah, there is lots of shit in that box (Score:2)
"Help me understand why the fuck is a firewall built in to systemd..."
To make it easier for Uncle Sam (and/or Emperor Xi) to bypass the firewall?
Re: (Score:2)
What firewall? There is none. Or do you mean the ability to tell a service it can't listen on certain sockets? That's just the equivalent of tcpwrappers, that's not a firewall.
So can you please give us some details? What is this new firewall functionality in systemd that you talk of?
Re:No alternatives are as good (Score:4, Informative)
Good for whom? The problem with the selection of systemd (or any other init system) is that 90% or more of the users will never notice. Because they never need to dig into it. For those that need to, systemd is a piece of garbage and the support for anything other than a Starbucks gaming laptop is met with NOTABUG WONTFIX. Because most people (Poettering and company included, I suspect) have never encountered systems that have complex, multi-homed network configurations. Or need to have user processes and disk mounts maintained across login/logout sessions. Or run no login X sessions to various remote displays.
Re: (Score:2)
Re:No alternatives are as good (Score:5, Insightful)
For example, a great many devices are USB, or have USB options. These have to be initialized the same way during system init as they would be during hot-plugging, it just makes sense to have both parts operate in the same way, but one has to happen during sytem initialization,and the other is done as part of a user interaction.
That's a problem that is solved by udev more than by systemd. In fact, my system runs fine with eudev, which is just systemd-udevd torn apart from the systemd source tree and repackaged as a standalone program by some kind volunteers. Saying today that systemd is required because it manages USB devices, after the management of USB devices was assigned to systemd without technical reasons years ago, sounds like circular reasoning to my ears.
Re: (Score:2)
A classic example of what Daniel Dennett
Re:systemd's advantages are not unique to systemd (Score:4, Interesting)
... and are (or can be) usually better done in a daemontools-ish infrastructure: simpler, securer, and more reliable.
I forgot to say "more flexible".
See Sections 03, 05, 07 & 08-10 of my recent document for some convincing examples.
TL;DR for the mentioned sections, just in case someone wants it: ... the list grows.
* Simple service definitions: better done with Bernstein chainloading.
* cgroups and resource management: can be done better with Bernstein chainloading.
* "Socket activation": better done with Bernstein chainloading and fd holding.
* Logging of individual services: better done with per-service logger; no need of binary logs.
* Anti-tampering of logs: can be better done with separate logger.
*
Re: (Score:2)
TLDR; version is - nobody has yet produced an init system that is even remotely competitive with systemd. Do this and then we can discuss if it's better.
An init system? Even Apple's Launchd system is better than systemd, with its weird plists. Ironically systemd tried to copy launchd, but the copy is worse than the original.
BTW, explain why cgroups should be in the init system at all and we can discuss further, but you won't, because cgroups should not be dependent on the init system.
Re:systemd's advantages are not unique to systemd (Score:4, Interesting)
You don't need a special daemon to use cgroups. It's basic OS functionality [man7.org].
cgroups v1: /sys/fs/cgroup/cpu /mnt/cgroup2 /sys/fs/cgroup/cpu/cg1 /sys/fs/cgroup/cpu/cg1/cgroup.procs
Mount a controller (v1):
mount -t cgroup -o cpu none
cgroups v2:
mount -t cgroup2 none
Create a cgroup:
mkdir
Move a PID into a cgroup:
echo $$ >
All of this can reasonably be done in init scripts. If redhat weren't so terrible at creating init scripts, perhaps we never would have wound up with systemd.
Re: (Score:2)
You certainly can. Feel free to write a script generator that translates unit files into init scripts.
If I were going to do that, which I'm probably not but you never know, I'd write an init script that reads unit files. I'm unlikely to do it for free, realistically, since I don't need to. Devuan exists, and other distributions without systemd exist.
If Debian wants people like me back, they can give me the option of another init system. If not, no big deal for me.
Re: (Score:2)
You are an idiot. Yes, you ARE an idiot.
BTW, explain why cgroups should be in the init system
1. To keep track of the process tree - classic Unix does not have any means to keep track of children launched by the daemon process.
What?
and for lwp and threads
The /proc filesystem was around a long time before systemd and we haven't even scratched the surface of that.
2. To keep track of resources and impose resource limits, such as CPU fairness, memory use or disk IO bandwidth.
None of which has anything to do with systemd and can controlled by tuning the CPU or IO scheduler.
cgroups should not be dependent on the init system.
Classic Unix does not have a reliable way to track process' children to be able to reliably kill an unresponsive or (intentionally) misbehaving daemon.
Considering you can track a process's children and unresponsive processes is generally blocked on I/O and systemd isn't going to be able to do anything about that. Anything CPU bound that much is eventually get the attention of the CPU schedu
Re: (Score:2)
See? Another idiot who knows NOTHING about Unix. Google for your edification: "daemon double fork". It explains why Unix process tree is not reliable.
Well 30 years and I'm still learning, however you didn't say anything about the process tree being unreliable you said: classic Unix does not have any means to keep track of children launched by the daemon process which is clearly not true.
Moreover, double fork is not some esoteric feature that nobody uses. It's the standard part of the daemonizing song-and-dance routine.
Detaching a process from a tty only seems to be an issue for deamons running under systemd. Furthermore a scenario for the very lockups you describe happen when a process is *unable* to attach to a tty, consuming memory until it can be terminated. Instead of being bl
Re: (Score:2)
Well 30 years and I'm still learning
Quite clearly not. I mean about you still learning, I hope you do know your age.
however you didn't say anything about the process tree being unreliable you said: classic Unix does not have any means to keep track of children launched by the daemon process which is clearly not true.
I told you to google "double forking". It will break ps's ancestry detection. Try it. Here's an explanation with pictures: https://iximiuz.com/en/posts/d... [iximiuz.com] - look for "Awaiting a grandchild process termination". In short, in Unix a grandchild process will be reparanted to the PID1 if its parent dies.
It's not at all atypical - an Apache process can launch child servers and if the main Apache process dies, child processes will
Re: (Score:2)
... none of which justify supporting cgroups inside the init system, because support for cgroups can be easily done with chainloading [jdebp.eu] commands.
cgroups are crucial to the functionality of systemd. In particular, they are also used to detect the daemon death (when no processes are left alive). Sure, you can use external utilities to do that, but they are going to be critical parts of the system. Moreover, cgroups manipulation takes comparatively few lines of code in systemd. Interaction with external wrapper scripts will necessarily take more.
What's even worse, it's going to be unreliable. If a wrapper script misbehaves or dies (because of an err
Re: (Score:2)
Exactly, and refactoring the critical parts as multiple loosely coupled components (init, chainloaders, etc) makes the implementation easier to reason about, and therefore easier to debug/maintain/customise.
No, it does not make it easier to "reason" about. In systemd you have a function that scans the cgroup and gives you a "true" result if it's empty. Replacing it with an external utility does nothing at all to make it easier to reason about.
Wow, interesting. Care to compare SLOC of cgroups code in systemd and nosh?
Sure. Let's do it!
sloccount on nosh results in 79,712 total lines of code. Not all of it is crucial, but I'm lazy. And anyway, it's not all! We also need at least dash, because nosh needs shell to function, that's at least 13,365 LOC. And then you'll also need some shel
Re: (Score:2)
With daemontools-like init/rc systems I can be perfectly sure the code in the chainloaders will not affect the init system, so entire classes of bugs are very unlikely to occur.
No, you can't be. Any chainloader can contain a bug that does "rm -Rf". Or it can simply hang indefinitely, leaving PID1 without any information about its state. And since PID1 in S6 does not manage cgroups, it can't reconstruct the state of the system. This introduces a whole new class of bugs that simply can not exist in systemd.
And they are not even hard to trigger in S6. For example, it won't be able to detect the OOM killer reliably. It's entirely possible for it to lose track of services if the OOM
Re: (Score:2)
And nope, it has nothing to do with service definition as you still need to at least encode dependencies.
Re: (Score:2)
Because wrappers can be written once and then used in every init system
No, they can not. They will encode the assumptions of the underlying init system.
and can be easily replaced with healthy workalikes in case this [lwn.net] kind of bug occured
Now you're completely incoherent. If your magic wrapper script has a root bug (and let's be honest, shell scripts will be choke-full of them) then this script will have to be fixed, just as systemd had to be fixed.
Which is why systems like s6-rc and anopa exist. Decoupled from the init system. Unlike systemd, and yet work much better.
Since they are not used in real world, of course they do not work better. In particular, S6 can't work with unmodified daemons that do double-forking. It can be retrofitted with cgroups, but then you'll have an unholy
Re: (Score:2)
You did not even skim through the documentation of the chainloaders, for example s6-setgiduid [skarnet.org] and create-control-group [jdebp.eu], or you will notice how they are init-agnostic. As was said here [jdebp.eu]
No, they are not init-agnostic. They can't be used with SysV init, for example. You'll need a wrapper script that would adapt them to SysV conventions.
First, most of the chainloaders are written in C/C++, in much clearer ways than that in systemd. Second, you surely did not even realise how simple the run scripts [jdebp.eu] are when you said they would be choke-full of bugs. Third, with chainloading I can be sure changes are limited to the 100 or so lines of code in a single chainloader. Vastly better than systemd.
I actually did. Quite a few of them are linked into nosh itself ("modularty-shmodularity"), like "move-to-control-group". It's also a TOTAL CRAP code. Yes, with caps. Example right here: https://gist.github.com/Cybera... [github.com] - a goto jump back into the body of an "if" statement. Mixed with incoherent error handling - the body of an error is printed to stderr with
Re: (Score:2)
Oh I see, no wonder the following code cannot be written in an init script for sysvinit: FETCHMAILHOME="/home/fetchmail" chpst -u fetchmail fetchmail -v --nodetach --daemon 551
Try that with Apache.
So one of nosh chainloader perhaps roughly as bad as some crap [slashdot.org] in systemd. Except that the code no longer resides in the memory or interacts with the init system after move-to-control-group chainloads into the next program, unlike the crap in systemd.
Nope. All of the code in nosh is crap. Like convert-fstab-services.cpp. And it's crap according to common definitions - cyclomatic complexity and other commonly recognized bad code practices. For example, "create_geli_bundle" function takes 13 arguments (and it's NOT an outlier). Also, the linked Slashdot poster is an idiot.
"Reliable service monitoring" and "Full SysV compatibility" requires crufts like double-forking and sysv-rc, which is by design [jdebp.eu] not supported by daemontools, runit and s6. As long as most daemons support foregrounding, and few (less and less) of the remaining ones do it this way, not a big deal.
You are not getting it. Double forking is not "required". It's what real-life programs do, including closed-source systems that can't be modified.
Moreover, even we
Re: (Score:2)
Re: (Score:2, Interesting)
Then please shed some light on why systemd's network renaming is a good thing.
On a system with a single network interface why is it better to have an essentially random interface name (that may even change e.g. when you replace your ethernet card) than the absolutely dependable eth0?
On a system with multiple network interfaces why is it better to have essentially random interface names than the basically also random ethX names that you WILL rename anyway?
Re: (Score:2)
Uh, that’s not systemd, that’s uDev. You can turn it off if you like, but the idea is that your network cards actually become reasonably predictable. SO yoyu have a computer with one NIC, you add a second one. Which one is eth0?
Re:systemd hate is disinformation (Score:5, Interesting)
Predictability in NIC names already existed. In the past distros would write rules to fix names of NICs once initially assigned. The first one detected would be eth0, but then a udev rule is saved so that this exact NIC (by MAC address) will forever be eth0, and any future cards become eth1, etc even if eth0 is later removed. And you have the option of manually editing the file, though I rarely did.
The new system is SUPPOSED to detect if a NIC is onboard, or in a PCI slot, and give it a name suitable to that. But even that is hit and miss. Sometimes dual-port NICs don't appear as 2 NICs but like SR-IOV subordinates of each other, which is wrong. Sometimes the motherboard onboard NICs are not properly recognized as such (I presume this is a BIOS error) and get labelled as being in add-on slots. Hell I've applied a BIOS update and seen PCI slots get relabelled; this didn't affect a NIC specifically but I saw the relabelling happen.
And finally, different motherboards will have different identifiers for their slots. Is the physical port I want to use on my addon card enp5s0, or enp94s0f1 ? It depends on the motherboard and I constantly need to check what it is for this machine.
So I've traded one consistent naming scheme which depends on the order of cards being detected over the machine's life, with one which depends on the BIOS naming scheme and how the NIC vendor labels their ports. I choose option 1.
Any just to make one thing clear, every single one of these things has happened to me personally and is not "I heard that this happens". Yes, I hate systemd, and it's not just joining the bandwagon - it's personal slights that have caused it.
Re: (Score:2)
On a system with a single network interface why is it better to have an essentially random interface name (that may even change e.g. when you replace your ethernet card) than the absolutely dependable eth0?
Because "eth0" is not reliable on all systems. Especially server ones.
Re: (Score:2)
Why wouldn't it be?
And what is to be gained by removing this predictability for other systems?
Re: (Score:2)
Re: (Score:2)
And of course, predictable names in systemd can be easily turned off, returning the "glory" of "eth0". It's a simple option.
Re: (Score:2)
For the same reason you should use UUIDs or labels as device names in fstab: the Linux kernel always enumerates devices dynamically, and you have no guarantee that the device with name $FOO is the same physical device every time.
It's a kernel issue. Userspace sees it by way of udev, but the issue existed long before udev became part of the systemd project (and it's still a fairly independent part).
Re:systemd hate is disinformation (Score:5, Insightful)
Since systemd preserves legacy and backwards compatability support and is just feature-additive, i don't see a problem with it.
What kind of legacy and backwards compatibility troubleshooting does systemd preserve when it endlessly loops waiting on something that will never start because it's waiting on something else that wont start. The end result is a clusterfsck booting rescue media when normally you can just ctrl-c and skip the bad startup, or reboot and do init single and start your daemons manually and you're off to the races.
What kind of 'everything-is-a-file' compatibility is preserved with such nonsense like systemd? You now have system calls and signals to do what used to be done with /etc/init.d. You now have a needlessly complex boot process to handle dependencies (which systemd does poorly if a single thing goes ary). Where at least a sysvinit system will be booted and half functional enough to shell in and fix the issue.
The fact of the matter is that systemd does NOT belong on servers, period.
Re: (Score:2)
I've seen more than enough init hangs on BSD systems because of a bad daemon that had trouble starting and would block up the init process. ANY init system that allows you to define a set of process that should be started before other processes could allow for the init system to end up getting blocked due to a misconfiguration. This is not unique to systemd and is not a problem introduced by it.
If you want the old network interface naming it would have been best to provide an option to enable that. Some wil
Re:systemd hate is disinformation (Score:4, Insightful)
Horse pockey. How long did it take before systemd stopped killing daemonized processes when a user logs out? It still doesn't support NFS background mounts. There are tons of things that it broke. Claiming otherwise is particularly silly propaganda.
Re: (Score:2)
"You can sometimes tell systemd not to break things that have worked for literally decades" is not an effective rebuttal to the charge that it has, in fact, broken things.
And it has a thoroughly broken idea of how to determine the success or failure of a "mount" command. If a mount command exits with status 0 but failed according to it's semantics, that is a bug that should be fixed in the mount utility. Poettering's imagination does not justify systemd pretending that a mount command that returned 0 actu
Re: (Score:2)
"You can sometimes tell systemd not to break things that have worked for literally decades" is not an effective rebuttal to the charge that it has, in fact, broken things.
So far I have not heard about a single broken idiotic feature that can't be accommodated by systemd. You might have to (gasp!) read documentation for it and change (GASP!) your scripts a bit, but that's it.
And it has a thoroughly broken idea of how to determine the success or failure of a "mount" command. If a mount command exits with status 0 but failed according to it's semantics, that is a bug that should be fixed in the mount utility.
This is exactly what bg mounts do. The mount command lies about the result. And they are not even needed - autofs infrastructure is a modern way to do it reliably.
Re: systemd hate is disinformation (Score:2)
Trump-hating Corporate Nazis sure do love systemd.
No, its CHOICE. (Score:5, Interesting)
Suppose systemd was the best thing since sliced bread, that doesn't mean I want to use it. Its like saying: Gnome/Wayland is the best desktop, nothing else matters, and the distro proceeds to break all the others by removing X11, etc because fixing each of them so they work with wayland is a waste of time...
And then there are the technical reasons, which are several, but i won't bring here (again) since many others have already commented.
When a distro decides that i should be using systemd and nothing else, what i see is that distro taking away my choice. Therefore i move to another distro.
So many excuses about "wasting time maintaining non systemd support", and yet there is a bunch of forks with much less volunteers making things work fine. The likes of Debian and Arch should learn from Devuan and Artix. Just how many people you think are behind those forks? And you tell me they couldn't do that job themselves?
Anyway if Debian retracts, that would be welcome. Otherwise Devuan it is. They provoked the schism in 2014, no point in crying about it 5 years later.
If Debian removes x86, you can try an entirely different distro like Void...
Re: (Score:2)
Suppose systemd was the best thing since sliced bread, ...
Noting that:
(a) Un-sliced bread stays fresh longer.
(b) Some people like slicing their own bread.
(c) Slicing it yourself gives you more control over the results.
Re: (Score:2)
Why not actually look up what systemd-logind or elogind does. That would tell you straight away.
Re: (Score:3)
I can give you one, as that was my personal motivation to move to systemd: setting dependable resource constraints on a service. We had a service that had the bad habit of eating up 100% memory if we let it, blocking out other background process (by getting the system into a swap storm). Using systemd I could set a limit on the service to never use more than 80%, and leave some memory for the rest of the system. And systemd, by using cgroups, can actually reliably promise that by using cgroups, and implemen
Re: (Score:3, Funny)
That says a lot more about you than it does about systemd.
Re: (Score:2)
| I love the newer longer command syntax.
So this is Unix, if you don't like the long commands, set up some aliases. Problem solved.
Re: (Score:2)
I don't miss catting, greping, awking, and seding my way through log files anymore than I miss writing 100+ lines of bash dependent on a fist full of environment variables just to start a service.
Huh? Systemd makes it so that you don't have to view a log file? I assume using cat and using whateverctl to view the systemd log file is equivalent, since you have to type some command to view the log file. And since when do you have to enter a fistful of environment variables to start a service? And if you do, why wouldn't you set it in your .login or .profile?