Busybox Deletes Systemd Support

ewhac writes: On 22 October, in a very terse commit message, Busybox removed its support for the controversial 'systemd' system management framework. The commit was made by Denys Vlasenko, and passed unremarked on the Busybox mailing lists. Judging from the diffs, system log integration is the most obvious consequence of the change.

Comments

Commit Message Missing for Me

[Kunedog]

Found it quoted elsewhere:

remove systemd support

systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.

The Commit Message

[Kunedog]

Found it quoted elsewhere:

remove systemd support

systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.

Re:The Commit Message

[Anonymous Coward]

I'm not aware of the politics in this, are they saying the systemd people are rude, or that they just refuse to make their code compatible?

Both.

People have found bugs that make systemd incompatible with existing programs, and rather than fix the bugs in systemd, the systemd people responded that the people who found the bugs should work around systemd and systemd didn't need to be compatible with existing code.

Basically systemd completely wrecks the UNIX way and makes the distros that use it absolutely unmaintainable if you're a sysadmin.

Re:The Commit Message

[SlashdotOgre]

Systemd has taken an all or nothing approach for its components, and it has enveloped several significant components such as udev/upower/udisks. What this means in practice is you either have to take all of systemd (i.e. replace your init system, syslog, etc.) to use any of the components it has absorbed or you need to fork and maintain what you need yourself.

Here's a personal example: I use Gentoo an MATE as a desktop which in turn uses upower for suspend & hibernate. The latest version of MATE requires the latest upower (now dependent on systemd) to support those functions. So now if I upgrade MATE, I have to either replace my init system (OpenRC) with systemd or not have those upower features on my laptop.

Forcing their users(or distros) hand like that is not playing well with other software and I applaud Busybox for standing up.

Re:The Commit Message

[ArmoredDragon]

I keep the systems configured so that in the event of a complete power outage, EVERYTHING must come back up without any intervention required. This is saves a lot of explaining when it's time to put out a fire and -- oh shit, the admin forgot to document how to get everything back up and running when somebody crashed their car into a nearby transformer and the UPS failed to signal the diesel generator to start, and now we're spending 3 days trying to get shit working again because the guy who set it all up quit about 5 months earlier. (Yes, I've seen exactly this happen before.)

The reboots are only necessary when testing changes to make sure that everything comes up the way it's supposed to in the event of a total loss of power. Sometimes this doesn't happen (for example, a new kernel image breaks ZoL, so after the reboot the array doesn't get mounted) and it might take multiple reboots before you've got it all set.

Re: The Commit Message

[Anonymous Coward]

There was a problem involving systemd, networking, and aiccu.

The aiccu maintainer demonstrated how systemd wasn't properly making sure that networking was up before attempting to start aiccu, something pretty much any other init system managed to do.

The systemd folk, by way of Red Hat basically told those using aiccu the same thing others were told: 'too bad, systemd isn't betting "fixed" because we don't see this as our problem.'

My opinion? Systemd is useless and makes more problems than it's worth. It has its mitts in far more than any init system should. It is a blight on system administration.

Re: The Commit Message

[Sesostris III]

I think the issue isn't that MATE depends on upower, rather that the latest version of upower depends on systemd. Perhaps MATE should not have required the latest version of upower, but that passes the problem to the MATE team rather than placing the problem where it belongs, which is with the systemd team.

As another poster has identifies, the problem seems to be that the systemd people aren't coding to interfaces. If they were, then dependencies wouldn't be on specific code, i.e. the implementations.

Upgrading software shouldn't require a change to the init system.

Re:The Commit Message

[drinkypoo]

That's what you get when you use open source software. If the developer decides they want to become dependent on systemd then it's their project and they can do what they like, and you have no control over it. If you don't like it your only option is to fork.

As opposed to what you get when you use closed source software. If the developer decides they want to become dependent on systemd (or whatever) then it's their project and they can do what they like, and you have no control over it. If you don't like it your only option is to go fuck yourself, because you don't get the source. You're going to have to move to a competing project, if you can even manage that because that closed-source program is actually standards-based (often it is not) and you're not locked in.

That's not a criticism, it's just a statement of the way it is. No point getting upset about systemd and other software that now relies on it, because it's not like the developer owes you anything.

The developer of a closed piece of software doesn't owe you anything, either. You paid for a piece of software, and aside from being fit for the stated purpose, they don't have to do anything for you. If they make architectural changes with which you disagree, you simply have no recourse, unlike OSS, where at least a fork is possible.

OSS is clearly superior to closed software in this regard. There's not even a counterargument to be made.

Re:The Commit Message

[thegarbz]

The logical follow up question is why does upower depend on systemd?

The team decided they didn't want to duplicate support for suspend/hibernate when there's already a tool which does so. At the same time they released a solution for those people without systemd:

UPower discontinued hibernate and suspend support in favor of systemd.
Because of this, we have created a compability package at
sys-power/upower-pm-utils which will give you the old UPower with
sys-power/pm-utils support back.
Some desktops have integrated the sys-power/pm-utils support directly
to their code, like Xfce, and as a result, they work also with the new
UPower as expected.

All non-systemd users are recommended to choose between:
# emerge --oneshot --noreplace 'sys-power/upower-pm-utils'
or
# emerge --oneshot --noreplace '>=sys-power/upower-0.99.0'
However, all systemd users are recommended to stay with sys-power/upower.

So what exactly is the problem? Why exactly is systemd so evil because someone else doesn't want to maintain a certain effort they are doing and instead hand off to another package, while even providing a compatibility option for the anti-systemd crowd?

Re:The Commit Message

[Antique Geekmeister]

> Both.

It's not all the systtemd people. But the problem starts right with the technical leadership, Leonart Pottering. systemd is attempting to do _too many_ things. Daemon management, _and_ logging, _and_ network management, _and_ automounting, _and_ privilege management, _and_ Leonart has stated that the gola is a "stateless Linux" where no system specific configurations are stored in "/etc": they're all migrated to systemd configuration tools.

The result is not only much too large, it's not cross-platform, because systemd _cannot_ run anywhere but Linux due to the kernel changes required. It thus creates a Linux lock-in, breaking broad availability and usability of services oriiginally compiled for Linux.

Re: The Commit Message

[jbolden]

The problem for lurkers who are actually interested in the facts that the AC is referring to is that aiccu wants to manually decide how to handle dependencies failing to resolve. Dependency resolution is a process management function where the individual daemon isn't going to have the information to make the correction. aiccu is having trouble because it doesn't want to cooperate with the design of systemd. There is no bug here, rather a clear cut system design question: where do dependency failures get resolved.

aiccu is easy enough to modify to patch to to get it to work with systemd which is what most distributions are doing, starting with Fedora in 2010. Of course those patches could be applied upstream and this problem could go away if aiccu wanted to cooperate.

Re: The Commit Message

[multi io]

How is it that sysvinit (and other init systems that operate via rote scripting) is able to handle aiccu flawlessly

It is not. As explained, the flaw is in aiccu itself. The init system cannot (and, consequently, does not) fix it.

Re: Dropping stderr and syslog messages...

[greenwow]

No. Being able to use less, grep, egrep, awk, cut, etc. is very important.

Re: Dropping stderr and syslog messages...

[Barsteward]

journalctl "pipe" [current tool of your choice]

configure system to forward all logs to syslog or rsyslog for the status quo

Journalctl is well worth getting to know http://www.freedesktop.org/sof...

Re: Dropping stderr and syslog messages...

[kthreadd]

The decision to drop stderr has made my life hell. I wish systemd guys understood how important it is to those of us that run servers.

Maybe I'm missing the point here, but there has not been any "decision to drop stderr". It's clearly possible to set where it should go:

StandardError=

Controls where file descriptor 2 (STDERR) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with one exception: if set to inherit the file descriptor used for standard output is duplicated for standard error. This setting defaults to the value set with DefaultStandardError= in systemd-system.conf(5), which defaults to inherit.

Re:So who wants to...

[Barsteward]

Here are some reasons for some people finding it being better with systemd in embedded. http://bec-systems.com/site/10...

Re:Well, at least someone is willing to say it!

[drinkypoo]

i bet you didn't like init scripts until you learnt how to code them by looking up and learning from a bash manual.

Some of us learned shell scripting before bash existed. We're perfectly comfortable with shell scripts, thanks. They are a central feature of the Unix operating system, and claiming that they are something to be avoided is only done by people who don't understand Unix.