openSUSE is migrating to the use of systemd for the upcoming 12.3 version, given the difficulties that emerged in trying to co-maintain two different init systems (SysV + systemd). While I am not going into the details of this choice (I leave this to more informed people), this has some consequences for software higher in the stack.
As ConsoleKit is deprecated, systemd offers its own daemon to keep track of sessions and assigned seats in a system. However, the KDE Workspaces rely on ConsoleKit to handle user switching, reboot, shutdown and a lot of ther things. Removing ConsoleKit would mean that users would suffer feature loss. On the other hand, with something that’s been deprecated and no longer actively worked on, you have issues with maintenance.
The solution the openSUSE KDE team took was to introduce support for systemd in the KDE Workspaces (this was mainly done by Raymond “tittiatcoke” Wooninck). The task was much easier than it seemed at first, because Red Hat people have already made patches to support systemd in Fedora. The part from the KDE team was to take these patches, test them for a few months (I’ve been running them smoothly for quite a while, along with others in the group), then apply them to the packages for the next version of the distribution. We’re currently testing a patch from Fedora that allows either ConsoleKit or systemd support runtime, without needing a compile-time dependency. Once sufficient data are available, it will be pushed to the distro packages.
Other patches were directly pushed upstream by Red Hat engineers, and include a better interaction between the workspaces’ power management infrastructure and systemd itself.
In short, the next version of openSUSE (12.3) should be fully capable of handling systemd. Of course, to ensure it’s as bug free as possible it requires testing, so why don’t you jump into the fray and share your experience with us?
Great work!
I’d really *really* like to see is KDE using systemd for its own user services though, like kded does today. Is that even remotely possible?
More shared code, more robust (one module crashes and the entirety of kded isn’t torn down), etc. I don’t know, it just sounds attractive.
Wait.. I had asked about this a few months ago in the KDE IRC and was told the usual “KDE exist on BSD win mac etc. so no systemd dep-t code” – now has this attitude changed, or are those patches downsteam only, specific to the SUSE/Fedora KDE builds? Thank you!
@isemenov These patches are downstream only, IIRC, minus the powermanagement things.
Is there any chance that shutdown in 12.3 will also power down the PC? Doesn’t seem to work with 12.2
@ian
It does work fine here (openSUSE Factory).
I think it’s really sad that those packages are not even on reviewboard. :/
One won’t but expect that systemd is more widespread and all this patching is broken if the maintainers don’t know about them.
@Aleix
Some bits touch stuff like KDM, hence I don’t think it’s even worth an effort to try putting them upstream (even though I would like that very much) due to the difficulty of getting patches approved for that. Most of the other bits are upstreamed instead (UDisks2 backend, inhibition support ,etc.).
I also would like to see this upstreamed; there’s little risk in putting them on reviewboard. So why don’t you do so, set plasma to be a/the review group, and see where we go? There’s zero point in multiple downstreams carrying such patches.
@Aaron You should contact the RH people (Lukas Tinkl is one of them, but I’m not sure who authored the other patches; I’ll ask) as they were the ones who did the work.
I did the initial patch. We were in a hurry to release, and user switching had been broken in systemd itself for a while (it also failed in GNOME), so we only managed to test shutdown and restart. I was planning to submit the patch for review when fully tested, but that didn’t get done. Recently, Martin Bříza (mbriza) got user switching working (it was triggering some bug or limitation in QtDBus as I had coded it – as I said, we weren’t able to test my code because systemd was broken itself when I had written it), and he changed the fallback to ConsoleKit to a runtime rather than compile time decision (which I personally don’t like all that much because of the overhead, but it has the advantage that you don’t have to attempt to figure out at compile time what will be used at runtime, my version was using a manual CMake flag for that). So I think this is ready for review now, we’ll submit it ASAP.
Thanks for the update, Kevin. I look forward to seeing this in KDE!
Pingback: OpenSUSE 12.3 adotterà systemd in maniera completa | oneOpenSource
Please drop systemd from OpenSuSE completely or make it available as a marginally supported option. I use SuSE since 1996, mostly on servers – but also on desktops. systemd is much too complicated (except in the most simplistic configurations) and will never come anywhere close to sys-v-init in its simplicity, maintainability and stability. Systemd is a very typical case of failure-by-design.
In the long run, systemd will do harm to OpenSuSE because of (missing) maintainability, complexity and server-unfriendliness. I believe, this is going to be far off from the “right way” of Linux.
It’s not too late!
Supporting two init systems is a maintenance nightmare. And I would add, I do not want to delve into this (IMO pointless) debate as the only thing that causes is stop energy for contributors and developers, and I’ve had enough by reading the opensuse-factory ML every time systemd is mentioned.