Per the wiki, seems elogind should start via first request on dbus or login https://wiki.gentoo.org/wiki/Elogind#Service I have it running via init script at boot. But I get no output from loginctl $ /bin/loginctl SESSION UID USER SEAT TTY 0 sessions listed. Looking at the pam files, I noticed nothing was sourcing /etc/pam.d/elogind-user, so I added part of that to /etc/pam.d/system-login --- a/etc/pam.d/system-login +++ b/etc/pam.d/system-login @@ -12,5 +12,7 @@ session optional pam_lastlog.so silent session include system-auth session optional pam_ck_connector.so nox11 +session optional pam_keyinit.so force revoke +session optional pam_elogind.so session optional pam_motd.so motd=/etc/motd session optional pam_mail.so Now when I login and run loginctl I have $ loginctl SESSION UID USER SEAT TTY c2 0 root seat0 tty1 c3 10001 wlt seat0 tty2 c4 0 root 3 sessions listed. Still playing around with all this, but seems like the pam integration is not complete. I was not able to have it start via dbus either. That maybe another bug that maybe application specific vs elogind or gentoo related. I am not sure that is correct as it causes issues for terminals, I do not get a prompt till I hit return. So something is not 100%.
I am not sure this is correct. Even with this in place at times I get nothing from loginctl on my one system, but another shows just root and not my user plus root. Not sure whats going on, still experimenting. The delay with terminal prompt was unrelated, bashrc + gnome-keyring issue.
Bit more background, I am still unsure of this. The reason for this was to get Enlightenment running under Wayland using elogind. I was not able to without this modification. With this modification was the first time I was ever able to start Enlightenment under Wayland. It ended up being just Xwayland, and not regular Wayland. But even XWayland I could not get going without this modification. It could be EFL/Enlightenment is not able to start a elogind session via dbus. Not sure if that would be an upstream issue or Gentoo specific dbus issue. I have noticed at times without this modification I did get session/seat output for root from loginctl. Still experimenting, but that was the background for why this maybe a necessary change.
Whatever displaymanager you use needs to have logind support. sddm would be such a displaymanager.
(In reply to Andreas Sturmlechner from comment #3) > Whatever displaymanager you use needs to have logind support. sddm would be > such a displaymanager. I am developing Entrance... https://github.com/Obsidian-StudiosInc/entrance logind/elogind support is an area I am looking into so I can support Wayland in addition to X. Just the same, a good deal in the E/EFL community use startx and do not run a DM. It is in part why Entrance feel into disarray and was broken. https://sourceforge.net/p/enlightenment/mailman/enlightenment-devel/thread/assp.034175451e.20170616221048.23ce91e2%40o-sinc.com/#msg35898495 There are various ideas as to how to deal with their MIA DM situation. The main author of EFL/E wants to use a E desktop session for the DM. https://sourceforge.net/p/enlightenment/mailman/message/35899464/ He presently does not use a DM https://sourceforge.net/p/enlightenment/mailman/message/35904335/ The previous Elsa/Entrance author does not even use a DM https://sourceforge.net/p/enlightenment/mailman/message/35899890/ Along with others in that tread https://sourceforge.net/p/enlightenment/mailman/message/35904765/ Anytime you bring up Wayland, they say Systemd. There is not much support or help to get things working under elogind. I have made posts to list without response. Just like their no DM situation. They are all more than happy to just use systemd. Thus something like this maybe necessary for anyone wanting to run E/EFL under Wayland without a DM. Since that seems like the upstream community may push others in that direction. Or indirectly encourage it by mentioning their setup.
Sorry, they not all use startx, just enlightenment_start. No startx for starting Wayland :)
DM aside my goal is for someone to be able to login and type enlightenment_start. Which would then launch E under a Wayland session. That is what would happen if you had systemd running on Gentoo I believe. Thus I think it should work just the same on Gentoo with elogind.
elogind is a drop-in replacement for systemd-login. So anything that supports systemd-login *almost* already supports elogind. It is just telling the build system configuration to be happy with libelogind. You can even keep including <systemd/logind.h>. It just works. KDE, for instance, does not need any modification to support elogind. The just ask dbus whether someone provides org.freedesktop.login1, and use that. Whether that interface is provided by systemd-login or elogind is completely irrelevant. Now to your problems: = PAM Login = =============== The installation of elogind should have added factory/etc/pam.d/system-auth to /etc/pam.d. This is all there is needed. You do not need /etc/pam.d/elogind-user at all, this was logind-user, and meant to be used for user private sessions (aka when a user starts "systemd --user"). I simply haven't removed that, yet. When I am on my way home tonight, I'll look into it whether there is a glitch in the build system that makes ninja to fail installing system-auth. = Start using dbus = ====================== The build system should have installed org.freedesktop.login1.service into <dbussystemservicedir>, which defaults to /usr/share/dbus-1/system-services. All that is needed is dbus to be started before any service is used that asks bus for org.freedesktop.login1. Applications that use the API rather than dbus, will use libelogind, which itself use dbus to connect to elogind. So down the line I am not quite sure why there are users reporting incorrect behavior when trying out dbus activation. At least for me it works just fine. = Wishes for the future = =========================== Please either CC me on such bugs, or open (a parallel) issue on github.com/elogind/elogind. I only learned of this by accident. I have just released two new versions of elogind this morning. Learning by accident that both might have serious issues with PAM- and dbus-activation is terrifying. :-/
Okay, I checked that. == /usr/share/dbus-1/system-services/org.freedesktop.login1.service == This file gets installed correctly. == /etc/pam.d/system-auth == This file belongs to sys-auth/pambase-20150213-r1, which must be merged with USE="elogind". The last line should be: -------- -session optional pam_elogind.so -------- @William: Please check whether you have USE="elogind" enabled pambase installed, and whether the dbus service file is where it should be on your system. It should look like this: -------- # This file is part of elogind. # # elogind is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [D-BUS Service] Name=org.freedesktop.login1 Exec=/lib64/elogind/elogind --daemon User=root --------
Is this issue still open?
(In reply to Sven Eden from comment #9) > Is this issue still open? We can probably close this.
Why is there a minus sign in front of that /etc/pam.d/system-auth entry, isn't that incorrect? "-session optional pam_elogind.so"
(In reply to Simon from comment #11) > Why is there a minus sign in front of that /etc/pam.d/system-auth entry, > isn't that incorrect? > "-session optional pam_elogind.so" See: http://wpollock.com/AUnix2/PAM-Help.htm Quote: -------- The “optional” control-flag means that the success or failure of that module has no effect. Generally, this flag is used for session modules only. A missing module acts like a “fail”, and the error is logged (via the system logging daemon, usually syslog). If a line in the configuration file starts with a dash, the error isn't logged. This can be useful for modules that may not be present, for example, a module for fingerprint authentication may not be present, but if it is, it should be used. --------
