Debian To Seek A General Resolution Over Their Init System Policy

[ssokolow]

How was the implementation botched?

Primarily that it crams too much complexity into PID 1 so, when something goes wrong, you can't kill and restart the misbehaving code.

The proper solution would be to have as much as possible in a helper daemon which PID 1 knows to restart if you kill it. (Sort of like how X11 desktops learned to split the anchor process for your X11 session lifespan from the window manager or whatever else originally served to hold the session open.)

It'd also enable live updating of all the code in the helper daemon as long as the interface between it and PID 1 was designed with stability in mind. Just update systemd and then ask the helper daemon to exit so PID 1 can "revive" the new version.

[zexelon]

Personally I think systeMd is all right. I have not actually found it to be any better or worse than init scripts to the average power user... basic users will never know the difference and quite frankly should never have to choose between systeMd or inIt.

[oiaohm]

Your actual code contributions are going to be welcome. Telling other people what to do, and how to do it, is likely not so well received in a volunteer organization.

This problem as a network administrator deploying systems is not something you can fix with code contribution. You need those running projects to wake up they have a problem because it require a restructure.

You have eudev and elogind that are basically forks out the systemd git tree. Both extracting different parts and horribly can be out of sync. So you can have the case that eudev is not working with elogind properly because their forks are based off two different commit numbers from the systemd git tree. Now why are package maintainers for distributions or even people like me going to want to waste out time dealing with a problem that is being caused because the projects are organised wrong.

Those that want init freedom (i.e. not depend on systemd) have mostly been primarily talk, and not contributing actual code with testing.

This is not 100 percent the case. Its the not depend on systemd is the problem.

Few packagers will not accept working and tested code, but being told how they must package rub many the wrong way with their limited volunteer time.

There is one problem here having organisational structure wrong results in needing more volunteer time. Because eudev and elogind are out sync due to being independent projects/forks this means you now have more packaging and testing to perform so costing more downtream volunteer time and more time for people like me testing solutions if we decide to use it. Of course you can expect package maintainers to give limited care about elogind errors because those errors are common with eudev let alone anything else.

Lets be blunt. Lot of distributions exist than claim not to be systemd reality you look at their packages they contain eudev and elogind so they are not absolute independent of systemd those project depend on systemd.

I would far prefer to see truthful "We are using systemd udev and systemd logind modified not to depend on the other parts of systemd." Then there would be no need to fork systemd twice to produce two independent projects that end up being incompatible with each other at random times. Instead you would have 1 fork off of systemd providing the 2 parts you need. With the possibility in time that could merge back into mainline systemd.

About time we have truth in advertising on systemd usage with that truth proper organisation setup of the required systemd fork as in a single fork off of systemd instead of the current 2 or more.

[jacob]

How was the implementation botched?

It's just apple fanboyism.

[jacob]

Can we just fork already? Linux and Redhatix need to go their own ways..

The fork is done, it's called Devuan, Void, Artix (and presumably a few others). Haven't you noticed?

[lowflyer]

Reading that whole fuss... er. discussion about the init system makes me really want to try out Devuan.

[Britoid]

Primarily that it crams too much complexity into PID 1 so, when something goes wrong, you can't kill and restart the misbehaving code.

The proper solution would be to have as much as possible in a helper daemon which PID 1 knows to restart if you kill it. (Sort of like how X11 desktops learned to split the anchor process for your X11 session lifespan from the window manager or whatever else originally served to hold the session open.)

It'd also enable live updating of all the code in the helper daemon as long as the interface between it and PID 1 was designed with stability in mind. Just update systemd and then ask the helper daemon to exit so PID 1 can "revive" the new version.

If the X Server goes down, your session is gone with it. The window manager doesn't hold the session.

[yoshi314]

I swear, this is just like Brexit.

[CochainComplex]

I swear, this is just like Brexit.

wait Boris Johnson is Debian maintainer?

[ssokolow]

If the X Server goes down, your session is gone with it. The window manager doesn't hold the session.

If the Linux kernel goes down, the same thing will happen, but you're missing the point.

The X server follows a similar session model to a terminal session. Starting up a session spawns some process and, when that process exits, the session ends. (eg. getty spawns whatever shell is specified for you in /etc/passwd and, when that goes away without being replaced (eg. exec some_other_thing), it punts you back to a login prompt.)

All your graphical apps then die because the X socket was suddenly closed from the other end. (Strictly speaking, they don't have to, but it's expected enough that I never found a way to hook that behaviour and override it in the Python bindings for GTK+ 2.x.)

The original way to do this is by having a script named ~/.xinitrc that gets called by the startx script. You edit it to spin up whatever processes you want in the background and then launch the window manager in the foreground. When the WM exits, execution of ~/.xinitrc will continue and, when the end is reached, the X server will take that as a signal to shut down.

(Don't believe me? Give yourself a ~/.xinitrc and try backgrounding the WM and putting a terminal window or text editor window as the thing that's run in the foreground. When you quit it, you'll get booted back to where you typed startx from. A variant of this model is still used for graphical login except it's a GUI tool called a Display Manager (eg. GDM, SDDM) that handles prompting for login before dispatching to such a startup script. See /usr/share/xsessions/ if you want to follow along from that point.)

As X sessions started to be longer (in real-world time) and more complex, it became standard practice to hand this responsibility off to a process called a session manager which is responsible for keeping track of what to launch on login and being as simple as possible otherwise, so that there'd be as little as possible to audit for stability.

(Originally, the purpose of the session manager was to implement a protocol that allows "restore whatever I had open when I logged out" behaviour to be automatic with the help of compliant applications.)

For KDE, the startkde script spawns a session manager named ksmserver. When you ask to log out, ksmserver exits, allowing the startkde script which spawned it to finish, and you get booted back to whatever launched it.

For LXDE, the session manager is named lxsession.

Some WMs (like AwesomeWM) still serve as their own session managers rather than spinning off the session lifetime handling into a separate process.

Don't believe me? Identify your desktop's session manager process and try kill-ing it. You'll get booted back to whatever you normally start your X sessions from.