Debian decides on systemd—for now

Posted Feb 13, 2014 21:53 UTC (Thu) by peter-b (guest, #66996)
In reply to: Debian decides on systemd—for now by dlang
Parent article: Debian decides on systemd—for now

it doesn't matter if it's running as a separate process if all the interfaces to it are private, subject to change at the whim of systemd, and unable to be replaced or run without the rest of systemd.

systemd-logind's interface is covered by systemd's Interface Stability Promise, so it's not subject to change on a whim. If someone else wants to make a competing implementation of the logind interface to replace systemd-logind, then they can do so.

systemd-logind uses the public interfaces to systemd's PID 1, which are also covered by the Interface Stability Promise. If you want to run systemd-logind without the rest of systemd, then you will need to provide an alternative implementation of those interfaces.

None of the interfaces that logind exposes or uses are "private", as far as I'm aware. Of course, you may have an example of one, and I would be delighted if you could highlight it for me.

Now, I suspect you are alluding to the changes in systemd 205. That was a case where a new (public) interface was added to the systemd PID 1, and systemd-logind was modified to utilise it. May I venture to suggest that (a) the systemd devs wouldn't have added the interface unless it did something they consider novel and useful and (b) if they think the interface is useful, it fairly obviously follows that they'd want to modify related software make use of it! It's certainly hardly evidence of unreasonable, incompetent or unfriendly behaviour.

This scaremongering about concealed interfaces that shift like quicksand beneath the feet of users and reimplementers (all subject to the malicious whim of the dark and mysterious cabal of systemd hackers) is neither accurate nor a valuable contribution to the init system discussion. Please stop it.

Debian decides on systemd—for now

Posted Feb 13, 2014 22:50 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

Yes. I think its important to really understand the logind situation.

The most important thing to note is that noone has yet gone through the trouble of building an independent implementation of a daemon to service the documented and stable D-BUS protocal. Nobody.

What Ubuntu has done is forked logind as a quick fix to avoid needing to run systemd as init. Logind prior to v205 was written with the PAXControlGroups multiple hierachy cgroups API in mind. logind prior to v205 did not depend on a single cgrourp manager entity and was free to write into the cgroup heirarchy itself..and it did so. But as of v205, systemd's provided logind daemon talks to the cgroup manager on the system as per the roadmap and guidance provided by kernel maintainers.

So it a lot of ways what we are seeing in v205 is a direct result of the kernel cgroup maintainer's decision (discussed widely in 2012!) to require a single writer model as part of cleaning up the cgroups API. systemd's implementation of the logind service provider as of v205 conforms to kernel's side expectations with regard to that.

The difficulty presented by logind change as of v205 has more to do with the fact that Ubuntu chose to fork logind as implemented by systemd instead of rolling an independent implementation to provide logind dbus API. Ubuntu could have chosen to spend the resources to re-implemented logind protocol using an independent daemon codebase that did not rely on cgroups at all. Using kernel cgroups is a design choice internal to the service talking the protocol...its not exposed in the protocol.

The Ubuntu devs are working hard to spin up cgmanager to be the single provider so they can patch logind v205 and beyond to work with cgmanager as a provider because they are still relying on a logind implementation that uses cgroups internally. And let me remind you cgmanager doesn't have a documented stable API yet for cgroup manipualtion. So the only cgroup manager API available for logind to support at present is systemd's.

All of this is entirely implementation details inside the scope of how a single logind daemon implementation can choose to work. The applications talking to it via D-BUS don't care about whether the logind daemon uses cgroups or not... or uses slices or not and systemd devs are not disrupting the stable protocol or creating new expectations on consumers at all. And given that systemd's implementation of logind service provider has always used cgroups heavily as part of its design, then it makes perfect logical sense for newest logind to require a central writer now that its been decided by the kernel cgroups maintainer that its the path forward for the cgroup rewrite.

I can't stress this enough, nobody as far as I know, is working on a independent implementation of the logind daemon to provide the stable documented logind protocol. I think that was a mistake on Ubuntu's part to fork this daemon instead of writing an independent implementation. If they had their own independent implementation, none of the changes in logind v205 would have impacted their ability to provide a working logind service and Debian would have a drop-in replacement to provide logind right now without the threat of holding up systemd or GNOME.

-jef