Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Busybox removes support for systemd

git.busybox.net

Post reply on HN
Print view View original

181–190 of 203 posts

Re: Busybox removes support for systemd

#181

Post by JdeBP »

the_why_of_y wrote: post #174
vezzy-fnord wrote: post #167

Earlier quoted context omitted.

There's been a lot of research in fault recovery through message logging and checkpoint-based methods that could be applied here, e.g. [1]. Of course, you use "academic" as a snarl world, so I don't think anything will convince you. The idea that the service manager would not be able to know the system and service states is completely false. Solaris SMF is a design that does, via its use of the configuration reposito…

That's very interesting, I didn't know SMF could do that. Let's see... init(1) is apparently restarted by the Solaris kernel automatically, which is different from Linux, no automatic kernel panic. https://github.com/illumos/illumos-gate/blob/master/usr/src/... * State File and Restartability * Premature exit by init(1M) is handled as a special case by the kernel: * init(1M) will be immediately re-executed, retaining…

> I never claimed any other single point of failure [in user-space] than the service manager.

If all of one's system and service management relies upon a system-wide software "bus", then another similar problem is what to do when one has restarted the "bus" broker service and it has lost track of all active clients and servers.

* https://bugs.freedesktop.org/show_bug.cgi?id=89847

* https://github.com/NixOS/nixpkgs/issues/7633

Related problems are what to do when one cannot shut down one's log daemon because the only way to reach its control interface is via a "bus" broker service, and the broker in turn relies upon logging being available until it is shut down. Again, this is an example of engineering tradeoffs. Choose one big centralized logger daemon for logging everything, and this complexity and interdependence is a consequence. A different design is to have multiple log daemons, independent of one another. With the cyclog@dbus service logging to /var/log and that log daemon's own and the service manager's log output being logged by a different daemon to /run/system-manager/log/, one can shut down the separate logging services at separate points in the shutdown procedure.

* https://github.com/systemd/systemd/issues/867

* https://bugzilla.redhat.com/show_bug.cgi?id=1214466

Re: Busybox removes support for systemd

#182

Post by skarnet »

JdeBP wrote: post #152
vezzy-fnord wrote: post #14

The technical aspect here is completely insignificant. All they did was remove a basic listener function that was already optional, used to communicate with systemd's socket activator without linking to libsystemd itself. And it seems only one Busybox daemon ever made use of it. The political significance is quite high, and I have to say I feel that this move, though perhaps a bit childish, is a valid signal to expre…

> The technical aspect here is completely insignificant. I disagree. My initial reaction was to lament the fact that BusyBox syslogd has lost the ability to be passed its socket as an open file descriptor. One may debate whether systemd's mechanism or UCSPI-UNIX (extended to datagram sockets) is the better way to pass such descriptors along. But it now has no mechanism. BusyBox syslogd is now less than it was.

Honestly, the people who use Busybox are probably aware of the problems - political as well as technical - with systemd, and most likely not using systemd in the first place because it's not exactly a good choice for embedded systems.

Also, for busybox syslogd, it does not matter at all whether you can hold its socket. syslog isn't a reliable mechanism anyway, and busybox is light enough that the non-ready period is really short.

So, on the technical side, the impact is quite minimal. On the political side, however, it looks like Denys made a splash, and I'm not going to complain about it. :)

Re: Busybox removes support for systemd

#183

Post by witty_username »

simoncion wrote: post #177
witty_username wrote: post #104

Earlier quoted context omitted.

How so? I was able to easily use systemd and the man pages seem decent. Maybe not the best documentation, but it seems reasonable.

In order to see the quality difference, you have to compare the docs to another project that you make extensive use of. I know that Postgresql's and Erlang's documentation is really rather good. So, go use Postgresql or Erlang for a slightly non-trivial project, then -now that you know about the topic that the docs cover- compare the quality of the systemd documentation to the documentation of either other project. P…

True, systemd's documentation isn't very bad though, it's reasonable (lack of internal documentation is pretty common in many open source projects).

Re: Busybox removes support for systemd

#184

Post by digi_owl »

otterley wrote: post #81
bossrat wrote: post #72

Earlier quoted context omitted.

you are exactly on point. the unix way is simplicity and transparency. systemd is complex and opaque. it's ok to have systemd's goals, but an additional goal should be "not a huge monolith"

What is the criteria by which you classify something as "opaque"? The documentation for systemd and its utilities is second to none.

Perhaps. Observed a lovely exchange a while back where a database was being publicly shamed for producing a poor unit file (i think they actually had the unit file launch a shell script that fired up the database).

Their response given was that it was the only way for them to avoid tying their database to the systemd signaling lib.

This was counted by one of the systemd devs claiming they could just use a socket that systemd provides.

But when i poked at the documentation, the only place such a "option" was mentioned was at the bottom of the man file for said lib. And it was presented as a note on the internal workings of systemd.

And you will find warning after warning about not using systemd internals, as the devs reserve the right to change the behavior of those internals at any time.

Re: Busybox removes support for systemd

#185

Post by digi_owl »

simoncion wrote: post #136
sobkas wrote: post #126

Earlier quoted context omitted.

sysvinit provided me with so much excitement that now I will take anything that just isn't sysvinit.

It only replaces sysvrc, [0] but I find the OpenRC-powered systems I admin to be quite sane and easy to manage. [0] But that's okay. I strongly suspect that when most folks say "sysvinit", they really mean "sysvrc". Hell, I used to be one of those folks until a while back.

I am worried even more that people people may well have used upstart for a number of years and still think they are using sysv, because upstart could grok the scripts without change.

But then i am sitting here using a distro that boot by way of a couple of flat files. Frankly i kinda like it, but then i grew up fiddling with autoexec.bat...

Re: Busybox removes support for systemd

#186

Post by digi_owl »

bsder wrote: post #85
Avshalom wrote: post #41

Earlier quoted context omitted.

Redhat does a lot of upstream development. By comparison Debian just has enough resources for keeping Debian running. SUSE seems to be an afterthought at this point. Ubuntu seems to mostly be concerned with itself.

> By comparison Debian just has enough resources for keeping Debian running. I think that's a touch unfair. The fact that Debian runs on the BeagleBone Black and RedHat doesn't puts a bit of lie to that statement.

If ARM became a big platform for servers or workstations, RH would probably roll out a ARM variant within the week (could be they even have test versions floating around their internal network).

In particular as Fedora already have ARM versions across the board.

https://arm.fedoraproject.org/

Re: Busybox removes support for systemd

#187

Post by digi_owl »

simoncion wrote: post #139
vezzy-fnord wrote: post #92

Earlier quoted context omitted.

And yet: https://git.devuan.org/explore They began work on a logind compatibility layer over ConsoleKit2, they're writing a NetworkManager alternative, they directly influenced and are supporting a udev alternative called vdev (which also has libudev compatibility), and a host of other things. For a rage-fork, it's pretty impressive. They're changing a lot. It's easier to just astroturf in the corner, though, I suppo…

> ...they directly influenced and are supporting a udev alternative called vdev... Have you a notion as to why they're using vdev rather than eudev? What appears to be the vdev introductory blog post makes no mention of eudev.

Possibly because vdev is a clean break, while eudev is still mostly about udev stripped from systemd.

And that stripping will be more complicated moving forward, as i recall a recent systemd release moved various bits from udev to a new systemd lib. Leaving the udev interfaces as stubs to be removed at some undetermined future date.

Re: Busybox removes support for systemd

#188

Post by digi_owl »

vezzy-fnord wrote: post #67
voidfunc wrote: post #65

Earlier quoted context omitted.

It's actually a pretty good system and IMO way better than previous attempts at init systems throughout Linux history.

Considering there's been ~15 of them, I doubt anyone has ever evaluated them comprehensively except post facto in light of the systemd integration.

Yeah the most documented such evaluation, the Debian process, seemed to only evaluate sysv, upstart and systemd (openrc was briefly mentioned but quickly dismissed).

The rest seems to have been executive decisions (with or without a "deal with it" meme accompanying), often by people already involved with systemd development.

Re: Busybox removes support for systemd

#189

Post by otterley »

digi_owl wrote: post #184
otterley wrote: post #81

Earlier quoted context omitted.

What is the criteria by which you classify something as "opaque"? The documentation for systemd and its utilities is second to none.

Perhaps. Observed a lovely exchange a while back where a database was being publicly shamed for producing a poor unit file (i think they actually had the unit file launch a shell script that fired up the database). Their response given was that it was the only way for them to avoid tying their database to the systemd signaling lib. This was counted by one of the systemd devs claiming they could just use a socket that…

Right, you're supposed to use the published interfaces. There's nothing particularly novel about that -- neither Microsoft nor Apple will support you if you don't use their public APIs, and in fact Apple will refuse to publish your software in their app store if you don't.

With respect to socket activation, a pretty useful tutorial, published by the systemd author, can be found here: http://0pointer.de/blog/projects/socket-activated-containers...

The DBus API can be found here: http://www.freedesktop.org/wiki/Software/systemd/dbus/

Re: Busybox removes support for systemd

#190

Post by digi_owl »

Sanddancer wrote: post #161
sandGorgon wrote: post #123

has anyone used Fedora 23 with Gnome, Wayland and Systemd ? I see a lot of religious handwaving around systemd, but F23 shows you the future of Linux desktop.. and it is brilliant. Right from network interfaces that dont change names when you swap hardware (powered by systemd) to making it damn easy to file crash bugs (using coredumpctl) to checking what services have failed "systemctl --failed" to a more secure grap…

I think the key word there is desktop. The systemd folks are desktop folks first and foremost, server operations be damned. coredumpctl requires root access, which means one has to be much more diligent in scripting automatic actions to handle core dumps. Failed services again are something that any supervisor service can handle and report -- launchd can get all that information from launchctl. Rootless X is somethin…

> server operations be damned.

I think it depends somewhat on how one define server.

The traditional hardware on shelf doing their designated task (i have seen it be referred to as "pet" servers) not so much, no.

But they do seem to heavily support container and virtual machine based servers ("cattle", to go with the pet reference earlier).

Post reply on HN