Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 599470 (elogind-support) - [TRACKER] sys-auth/elogind - Integration into Gentoo
Summary: [TRACKER] sys-auth/elogind - Integration into Gentoo
Status: CONFIRMED
Alias: elogind-support
Product: Gentoo Linux
Classification: Unclassified
Component: Overlays (show other bugs)
Hardware: All Linux
: Low enhancement with 4 votes (vote)
Assignee: Sven Eden
URL: https://github.com/elogind/elogind
Whiteboard:
Keywords: Tracker
Depends on: 599494 681200 681330 681334 682196 598615 599474 599482 599490 599492 599498 599502 599504 599506 607352 613398 620896 620948 622800 633336 633338 636240 639432 652340 667592 667960 668522 669558 670930 673406 673426 681300 681328 681332 681344 682126 682134 686014
Blocks: elogind-default
  Show dependency tree
 
Reported: 2016-11-11 14:06 UTC by Sven Eden
Modified: 2019-10-14 14:10 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Implementation plan - 2016-11-11 (README_elogind_plan.txt,1.06 KB, text/plain)
2016-11-11 14:06 UTC, Sven Eden
Details
Implementation plan V2 - 2016-11-11 (README_elogind_plan_2.txt,1.44 KB, text/plain)
2016-11-11 14:41 UTC, Sven Eden
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Eden 2016-11-11 14:06:54 UTC
Created attachment 452982 [details]
Implementation plan - 2016-11-11

This Tracker is used to track the progress of integrating sys-auth/elogind into Gentoo.

About elogind:
--------------
Elogind is the systemd project's "logind", extracted out to be a stand-alone daemon.  It integrates with PAM to know the set of users that are logged in to a system and whether they are logged in graphically, on the console, or remotely.  Elogind exposes this information via the standard org.freedesktop.login1 D-Bus interface, as well as through the file system using systemd's standard /run/systemd layout.  Elogind also provides "libelogind", which is a subset of the facilities offered by "libsystemd".  There is a "libelogind.pc" pkg-config file as well.

About me:
---------
I am no official gentoo developer. I do proxy maintain a few packages, but that's it.
This means, that the following implementation plan is just a suggestion, open for debate.

About the implementation plan:
------------------------------
To be able to edit the implementation plan, I will not post it directly, but attach it as a text file.

Why the fuss?
-------------
While Consolekit is no longer maintained upstream, the fork ConsoleKit2 is under development.
Although this works pretty well, development elsewhere goes to use logind as a session tracker.

Example: To use Wayland, KWin needs to communicate with logind DBus API. If this is not provided, no native Wayland session can be started. To make this work, the logind DBus interface needs to be installed (this does neither require using systemd nor logind). Elogind does provide such an interface.

This site has some more details about what logind is used for:
http://blog.davidedmundson.co.uk/blog/systemd-and-plasma


Any suggestions, updates, help and other feedback is highly welcome and appreciated!
Comment 1 Mart Raudsepp gentoo-dev 2016-11-11 14:20:27 UTC
If this goes in, we should also be able to support GNOME without systemd officially. So CCing us.

What's the status of elogind itself? Especially in regards to tracking changes done to logind code in systemd as of late? Does it see active syncing of logind code changes done in systemd or anything of that sort? I.e, is elogind an active upstream? Latest change seems from March, but maybe that's just because there's nothing changed in systemd for logind that could use porting to elogind?
Comment 2 Sven Eden 2016-11-11 14:41:48 UTC
Created attachment 452994 [details]
Implementation plan V2 - 2016-11-11

Added the involvement of the respective package maintainers.
Comment 3 Sven Eden 2016-11-11 14:45:19 UTC
(In reply to Mart Raudsepp from comment #1)
> If this goes in, we should also be able to support GNOME without systemd
> officially. So CCing us.

The only interesting ebuild I found so far was gvfs.

> What's the status of elogind itself? Especially in regards to tracking
> changes done to logind code in systemd as of late? Does it see active
> syncing of logind code changes done in systemd or anything of that sort?
> I.e, is elogind an active upstream? Latest change seems from March, but
> maybe that's just because there's nothing changed in systemd for logind that
> could use porting to elogind?

Actually I just got involved within elogind itself. Once I have completed opening bugs for the packages I have already updated, I plan to analyze what changes where made to systemd-logind since version 219 that might be relevant for elogind.
Comment 4 Mart Raudsepp gentoo-dev 2016-11-11 15:02:02 UTC
(In reply to Sven Eden from comment #3)
> (In reply to Mart Raudsepp from comment #1)
> > If this goes in, we should also be able to support GNOME without systemd
> > officially. So CCing us.
> 
> The only interesting ebuild I found so far was gvfs.

Usage of logind is rather widespread in GNOME for some basic functionality like being able to suspend, etc. There are no deps in ebuilds for this, it relies on something providing the org.freedesktop.login1 DBus services.
Currently we force systemd for GNOME stuff, because it's the only in-tree provider of those services.
There is a project to bring back these functionalities by reverting the removal of CK support in various packages (https://forums.gentoo.org/viewtopic-t-1022050.html), but this is a community effort we can not support officially due to it being a real long-term solution, instead we want an alternative logind implementation and if that implementation is up to snuff, things should just work.
Hopefully elogind is one such option for this here. All of the current GNOME team members are quite happy with systemd, so we've had no interest in devoting our own time significantly to this, but if you bring us elogind, we can revise our non-systemd blockers, stance of not supporting things without systemd and so on.

Good luck in your efforts :)
Comment 5 Sven Eden 2016-11-11 15:38:51 UTC
(In reply to Mart Raudsepp from comment #4)
> Usage of logind is rather widespread in GNOME for some basic functionality
> like being able to suspend, etc. There are no deps in ebuilds for this, it
> relies on something providing the org.freedesktop.login1 DBus services.
> Currently we force systemd for GNOME stuff, because it's the only in-tree
> provider of those services.

Then it is good that elogind provides org.freedesktop.login1 DBus services. :-)

Maybe it will be like with kde-plasma/powerdevil. The only change needed was to have the ebuild accept elogind as a substitution for consolekit.
Comment 6 Mart Raudsepp gentoo-dev 2016-11-11 17:02:03 UTC
Didn't realize we'd get all the tracking notifications. Removing gnome@ to not bother who isn't maybe interested quite yet, and CCing in person instead to monitor the development. Once things are further along, I'm sure re-adding us where relevant is acceptable (and if it needs action in our package, rather assign to us for these bugs once the base is in).

Wrt changes, in many places there simply are no dependencies at all and nothing to change for the package itself. We just need to ensure that the user has logind services running; currently we are forced to do so by making it hard to not have systemd, documenting that systemd is needed, etc. Based on some of the bugs tracked via here, I see there are various things that would want to then link to some elogind library instead of libsystemd, but I don't think these are the main things, nor would all of them be able to be satisfied by elogind, as there are e.g journald stuff, etc; and elogind doesn't handle that stuff, nor should it.
Comment 7 Sven Eden 2016-11-11 17:19:32 UTC
(In reply to Mart Raudsepp from comment #6)
> Wrt changes, in many places there simply are no dependencies at all and
> nothing to change for the package itself. We just need to ensure that the
> user has logind services running; currently we are forced to do so by making
> it hard to not have systemd, documenting that systemd is needed, etc. Based
> on some of the bugs tracked via here, I see there are various things that
> would want to then link to some elogind library instead of libsystemd, but I
> don't think these are the main things, nor would all of them be able to be
> satisfied by elogind, as there are e.g journald stuff, etc; and elogind
> doesn't handle that stuff, nor should it.

That is exactly the catch. sys-auth/elogind provides the login1 dbus service and libelogind to link against, plus the needed headers.

So the only part that can be substituted is libsystemd-login. The package then needs to include <elogind/sd-login.h> instead of <systemd/sd-login.h> and that's it.

Packages that use systemd-journal or any other non-logind-part, are of no concern.

I found 74 packages installed on my system with at least one systemd reference in them. Most only install service files. Some make use of systemd-journal. Only 10 make use of libsystemd-login, and I have now submitted all of them but x11-base/xorg-server.
The latter has to be started with "-keeptty" to add systemd-login/elogind integration, and that argument is strictly for debugging.

--------

However, I am done so far.

The ebuilds posted in the blocking bugs and published via layman/seden enable the following on my systemd:

1) SDDM starts with full support for shutdown, reboot, suspend and hibernate.
2) Plasma 5 starts without ConsoleKit support. Shutdown, reboot, suspend and hibernate are provided and work.
3) Suspending my laptop and waking it up later are significantly faster than while using ConsoleKit2.

What does not work:

A) When I plug in an USB key, it does not get recognized. It doesn't even show up in dmesg, so I guess this has nothing to do with elogind. But at least testing whether mounting of external drives work isn't done yet.
B) When issuing a shutdown or reboot command from the Plasma Menu, the system drops back to SDDM and does not continue to shutdown or reboot. So the result is the same as simply logging out.

These are the main issues I'll dig into next week.
Comment 8 Sven Eden 2016-11-11 17:53:20 UTC
(In reply to Sven Eden from comment #7)
> A) When I plug in an USB key, it does not get recognized. It doesn't even
> show up in dmesg, so I guess this has nothing to do with elogind. But at
> least testing whether mounting of external drives work isn't done yet.

Fixed in Bug 599494 (sys-apps/dbus: Add elogind support) :
Brian Evans found a typo in my patch that caused elogind to not being supported by dbus at all.

Once fixed I can attach, mount, unmount and eject USB drives without any issues.
Comment 9 Michael Palimaka (kensington) gentoo-dev 2016-11-12 11:32:19 UTC
Sven, thank-you very much for working on this. This is a really big step in keeping choice alive on Gentoo.
Comment 10 Pacho Ramos gentoo-dev 2016-11-22 19:56:24 UTC
Did anyone contact Funtoo people? If I don't misremember, they are doing efforts to maintain Gnome running on non-systemd setups... then, maybe they will be able to test the changes and, anyway, they would likely be interested in the short term
Comment 11 Michael Palimaka (kensington) gentoo-dev 2016-12-29 13:01:44 UTC
Has anyone come up with description for the elogind USE flag yet?
Comment 12 Sven Eden 2016-12-29 13:06:08 UTC
(In reply to Michael Palimaka (kensington) from comment #11)
> Has anyone come up with description for the elogind USE flag yet?

I have different via metadata.xml, but that is only because the packages make different uses. It is a bit vague.

Maybe a general flag might be better, like:
  <flag name="elogind">Use <pkg>sys-auth/elogind</pkg> for session tracking.</flag>
Comment 13 Sven Eden 2017-02-13 08:47:57 UTC
Sorry for being absent so long. I have worked on getting elogind up to the systemd-226 code base, which is now complete, but still needs testing.

However, I have some very serious personal problems at home, which I have to attend to, so my spare time is really sparse at the moment. I do hope to be able to catch up soon.
Comment 14 Martijn Schmidt 2017-02-25 13:33:38 UTC
I've been testing your patches running sys-auth/elogind-225.9999 from your overlay. Compared to the in-tree sys-auth/elogind-219.12-r5 things that I have noticed as fixed so far include:

- Opening Konsole and trying to get a root shell with "sudo -s" doesn't freeze the PC.
- Hitting the reboot button from the Plasma Application Launcher actually reboots the PC instead of sending one back to sddm (Xorg) or freezing the PC (Wayland).
Comment 15 Michael Palimaka (kensington) gentoo-dev 2017-06-03 13:18:02 UTC
I've moved the regular elogind USE mask to a stable mask:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fcd988a5427b136abd031da00faff8fef4c9235f
Comment 16 Martijn Schmidt 2017-06-03 19:44:52 UTC
Are we still missing a bug for elogind integration of x11-apps/xinit so it can be rolled out officially? The patched ebuild is available in Sven's overlay and I haven't noticed any problems with it over the past few months of use.
Comment 17 Sven Eden 2017-06-05 12:23:50 UTC
(In reply to Martijn Schmidt from comment #16)
> Are we still missing a bug for elogind integration of x11-apps/xinit so it
> can be rolled out officially? The patched ebuild is available in Sven's
> overlay and I haven't noticed any problems with it over the past few months
> of use.

I never opened a bug, because I wasn't entirely sure, whether the patch is needed or not. It is, as far as I can test and see, somewhat optional.

However, bug 620896 opened.

Thank you very much for the reminder!
Comment 18 Michael Palimaka (kensington) gentoo-dev 2017-06-25 09:53:23 UTC
We have a wiki page now: https://wiki.gentoo.org/wiki/Elogind
Comment 19 Martijn Schmidt 2017-10-02 21:03:14 UTC
By the way, from the KDE Plasma 5.11 release announcements.. "Furthermore, it is now possible to use ConsoleKit2 instead of logind for setting up the Wayland session, extending the number of supported platforms."

https://www.kde.org/announcements/plasma-5.10.95.php

I assume Gentoo is still moving forward with the elogind integration, since it's good to have diversity, just thought I'd put this piece of news in the comments.
Comment 20 Michael Palimaka (kensington) gentoo-dev 2017-10-03 10:33:24 UTC
(In reply to Martijn Schmidt from comment #19)
> I assume Gentoo is still moving forward with the elogind integration, since
> it's good to have diversity, just thought I'd put this piece of news in the
> comments.

Sure, we'd like to support as many options as possible. It just so happens that elogind integration seems to get the most love right now because it's well used inside Gentoo KDE team. Also, it sure doesn't hurt that it "just works" and the maintainer is a Gentooer (hi Sven)!
Comment 21 Pavel 2018-07-25 10:31:59 UTC
Please check out https://bugs.gentoo.org/662088
Comment 22 Larry the Git Cow gentoo-dev 2019-03-20 09:51:27 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bea47cee314829edbb41453d1e89fa1d1d3f9993

commit bea47cee314829edbb41453d1e89fa1d1d3f9993
Author:     Mart Raudsepp <leio@gentoo.org>
AuthorDate: 2019-03-20 09:36:42 +0000
Commit:     Mart Raudsepp <leio@gentoo.org>
CommitDate: 2019-03-20 09:50:44 +0000

    profiles/desktop/gnome: globally enable elogind, disable consolekit
    
    GNOME really desires a logind provider. Now that the core gnome desktop
    supports elogind, we can default enable it in GNOME profile with a clean
    gnome-base/gnome install path without systemd. For this we also need to
    disable consolekit from desktop profile (until it's still enabled there),
    as some packages block between USE=consolekit and USE=elogind.
    profiles/desktop/gnome/systemd relies on the systemd profile now
    use.masking USE=elogind globally (a change I made some days ago), and
    enabling USE=systemd in its place, so should be no regressions there.
    
    Because stable doesn't have a usable non-systemd GNOME setup anyways,
    desktop/gnome profile wasn't out of the box usable, thus we don't
    need to concern ourselves for stable users here and get the profile
    working for ~arch users -- before this everyone using gnome should
    have been using desktop/gnome/systemd instead anyway.
    
    Bug: https://bugs.gentoo.org/599470
    Signed-off-by: Mart Raudsepp <leio@gentoo.org>

 profiles/targets/desktop/gnome/make.defaults | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 23 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-03-23 06:46:12 UTC
Could someone be kind enough to provide an official porting guide that I could throw at upstream?
Comment 24 Andrea 2019-06-10 15:14:00 UTC
Hello,

after upgrading the profile to default/linux/amd64/17.1/desktop/plasma, consolekit at_console /var/run/console stopped working because it requires a symlink from /usr/lib64/ConsoleKit/run-sessions.d/pam-foreground.ck->/usr/lib/ConsoleKit/run-session.d/pam-foreground-compat.ck... It seems ConsoleKit doesn't install correctly on the 17.1 profiles. Furthermore I already had to patch by hand dbus-1.12.12-r1 ebuild to add "--with-console-auth-dir=/var/run/console" to make it work with consolekit at_console logic, because that already has been obsoleted by default in dbus.

The dependency on cgroup and inotify, timerfd, eventfd doesn't sound problematic at all... there's simply no point not to build a kernel without cgroup/inotify/timerfd/eventfd for a plasma profile.

So to me it sounds like it's time to switch at least the plasma profile to default on elogind which would solve many issues at once by setting USE="-consolekit elogind" by default.

Thank you.
Comment 25 Andreas Sturmlechner gentoo-dev 2019-06-10 15:18:12 UTC
That's what we are tracking in bug 682160 already.

Please file a bug consolekit.
Comment 26 Andrea 2019-06-13 01:25:49 UTC
(In reply to Andreas Sturmlechner from comment #25)
> That's what we are tracking in bug 682160 already.
> 
> Please file a bug consolekit.

I'm not sure if it's worth filing a bug for consolekit 17.1 profile that broke at_console, because stable dbus already obsoleted consolekit at_console, I was patching in back in dbus manually or I wouldn't have noticed.

In my configuration I did find one regression with elogind today: the backlighthelper of plasma (X using modesetting driver so xbacklight doesn't work and the backlighthelper started by dbus is required) didn't work anymore.

It turns out polkitd elogind support requires polkitd to open /proc/pid/status and I had /proc mounted with the hidepid=2,gid=proc option.

After I added the polkitd user to the proc group, that regression is gone (that wasn't required when polkitd was built for consolekit). So far so good with USE="elogind -consolekit" on default/linux/amd64/17.1/desktop/plasma.

I thought of reporting this here in case other runs into any issue with the backlighthelper if using the hidepid proc mount option.

Thanks.
Comment 27 Rafal Kupiec 2019-07-28 10:41:56 UTC
https://forums.gentoo.org/viewtopic-t-1099870.html

Seems that is it not working properly...
Comment 28 Andreas Sturmlechner gentoo-dev 2019-07-28 10:43:04 UTC
This is a tracker bug, not individual troubleshooting.