elogind status

elogind status

[Andy Wingo]

Hi :)

To pick up a thread from May, I was poking at elogind recently.  A bit
of recap as to how things got here, then the status.

To recall: by default on a Unix system, the user has full control over
their space, but can't do very much about the system itself.  When D-Bus
came along, more and more system services were exposing interfaces
allowing users to take actions on the system, but that bent the policy
too far towards the user -- the admin had no control.  So things started
going the other way again, with PolicyKit brokering privileged actions,
and the admin could specify rules saying under what conditions a user
would be able to take a privileged action, such as rebooting the system,
inhibiting suspend, etc.

One of the conditions that PolicyKit can use to determine whether an
action is authorized or not is knowing whether the user is physically
sitting in front of the computer or not.  This information used to be
maintained by ConsoleKit, which implemented login tracking by running a
wrapper around sessions -- like ck-launch-session.  It exposed a D-Bus
interface that programs could query.

But ConsoleKit is unmaintained now.  The CK developers joined the
systemd team, and shifted to work on logind, which is a part of systemd.
Logind tracks sessions by integrating with PAM -- every time a user logs
in, logind can know it, add some metadata to their PAM session, and
likewise for logout.  This also lets logind know how they log in --
graphically, at the console, remotely, etc.  Logind exposes a C API, in
practice these days part of libsystemd, but it's more common for
programs to use logind's D-Bus API.

I want GNOME on Guix :)  GNOME used to support ConsoleKit but doesn't
any more.  There is a ConsoleKit2 project that started recently but
without buy-in from GNOME I don't see a future for it.  GNOME really
needs the org.freedesktop.login1 D-Bus interface -- really wants it.  So
I thought, OK, let's pull logind out of systemd, and see where that gets
us.

The result is https://github.com/andywingo/elogind.  It provides:

  * a logind-compatible API with a different library name, libelogind

  * a pkg-config file, libelogind.pc

  * a daemon, elogind

  * a PAM module, pam_elogind.so

  * a query/control utility, loginctl

It might be worth it to install more compatibility interfaces for
systemd, e.g. libsystemd.so, or a symlink for <systemd/sd-login.h> to go
to <elogind/sd-login.h>.  Or perhaps we should just provide the systemd
header files with the systemd names.  In practice this means that
building packages that use the C interfaces need a bit more munging in
Guix to replace names.

In the patches I sent to this list, we have also a service which runs
elogind, and the facilities to integrate pam_elogind.so with the rest of
the system.  The PAM integration is really horrible and I'd be
interested in other options; see footnote for my os-config.scm.

Upstream logind integrates with systemd to ensure that user sessions are
run in cgroups, which is a pretty neat feature.  They manage cgroups
with a hierarchical "slice" abstraction.  Perhaps DMD should do this at
some point.  Using cgroups also lets logind know when a process was
started by a user but the user has logged out, and optionally lets the
administrator kill user processes when they log out.  So, elogind will
expose information about users, sessions, and seats, but for now not
slices.  Most logind users don't care so this is OK.

Andy

[*] Configuring elogind

First of all you need some extra file systems.  These paths provide a
documented interface to logind information:

  (file-system
    (device "systemd")
    (mount-point "/run/systemd")
    (type "tmpfs")
    (check? #f)
    (flags '(no-suid no-dev no-exec))
    (options "mode=0755")
    (create-mount-point? #t))
  (file-system
    (device "systemd")
    (mount-point "/run/user")
    (type "tmpfs")
    (check? #f)
    (flags '(no-suid no-dev no-exec))
    (options "mode=0755")
    (create-mount-point? #t))

Since elogind wants to manage the content of these directories, it has a
little internal rm-rf helper to clean them when elogind starts up.  But
that helper is really conservative and doesn't want to remove files on a
filesystem that's not tmpfs or ramfs, hence these mounts.

Secondly you need to configure a pam-elogind module.

  (define pam-elogind
    (pam-entry
     (control "required")
     (module #~(string-append #$elogind "/lib/security/pam_elogind.so"))))

We add the pam module to the base pam services:

  (pam-services
   (base-pam-services #:additional-session-modules (list pam-elogind)))

Now we have to add that module to *all* services that can log in that
elogind should know about :(  In my case:

  (services
   (let ((motd (text-file "motd" "
This is the GNU operating system, welcome!\n\n")))
     (list (console-font-service "tty1")
           (console-font-service "tty2")
           (console-font-service "tty3")
           (console-font-service "tty4")
           (console-font-service "tty5")
           (console-font-service "tty6")

           (mingetty-service "tty1" #:motd motd #:additional-session-modules (list pam-elogind))
           (mingetty-service "tty2" #:motd motd #:additional-session-modules (list pam-elogind))
           (mingetty-service "tty3" #:motd motd #:additional-session-modules (list pam-elogind))
           (mingetty-service "tty4" #:motd motd #:additional-session-modules (list pam-elogind))
           (mingetty-service "tty5" #:motd motd #:additional-session-modules (list pam-elogind))
           (mingetty-service "tty6" #:motd motd #:additional-session-modules (list pam-elogind))
           (static-networking-service "lo" "127.0.0.1"
                                      #:provision '(loopback))
           (syslog-service)
           (guix-service)
           (nscd-service #:name-services (list nss-mdns))

           (lsh-service #:additional-session-modules (list pam-elogind))
           (slim-service #:additional-session-modules (list pam-elogind))
           (avahi-service)
           (wicd-service)
           (upower-service)
           (colord-service)
           (geoclue-service)
           (polkit-service)
           (elogind-service)
           (dbus-service (list avahi wicd upower colord geoclue polkit elogind))
           (udev-service #:rules (list lvm2 fuse alsa-utils upower colord elogind)))))

It's a bit of a cross-cutting concern and I don't know what to do about
it exactly.  But, with all of this, and the patches I have sent,
pam_elogind.so does tell logind about users.  I rewired polkit to use
elogind for console information but I haven't tried going back up the
stack to get a GNOME session.  Future work, I guess, and help is very
much welcome :)  If you are interested in hacking on elogind I am sure
you will find things to do.  Let me know and I'll add you to the
maintainers.

Cheers,

Andy

Re: elogind status

[Claes Wallin (韋嘉誠)]

On Fri, Aug 21, 2015 at 12:33 PM, Andy Wingo <wingo@igalia.com> wrote:
> Hi :)
>
> To pick up a thread from May, I was poking at elogind recently.  A bit
> of recap as to how things got here, then the status.

[ . . . ]

> I want GNOME on Guix :)  GNOME used to support ConsoleKit but doesn't
> any more.  There is a ConsoleKit2 project that started recently but
> without buy-in from GNOME I don't see a future for it.  GNOME really
> needs the org.freedesktop.login1 D-Bus interface -- really wants it.  So
> I thought, OK, let's pull logind out of systemd, and see where that gets
> us.
>
> The result is https://github.com/andywingo/elogind.  It provides:
>
>   * a logind-compatible API with a different library name, libelogind
>
>   * a pkg-config file, libelogind.pc
>
>   * a daemon, elogind
>
>   * a PAM module, pam_elogind.so
>
>   * a query/control utility, loginctl

This is great to hear!

How much do you know about what uselessd, nosh and the Ubuntu logind
shim and how they did things? I don't know anything, I just know these
things exist.

I want GNOME on Guix too! Currently running Guix on NixOS mostly for
this reason (they use systemd).

-- 
   /c

Re: elogind status

[Andy Wingo]

On Fri 21 Aug 2015 13:48, "Claes Wallin (韋嘉誠)" <gnu@clacke.user.lysator.liu.se> writes:

> How much do you know about what uselessd, nosh and the Ubuntu logind
> shim and how they did things? I don't know anything, I just know these
> things exist.

No idea!  Could be some things didn't exist back in May?

Looking now:

 * uselessd is unmaintained, based on an old fork of systemd, actively
   hates things I don't care about, aims to replace systemd and not just
   logind

 * nosh: doesn't implement the login1 d-bus interface

 * Ubuntu logind shim: Couldn't find information about this.  Ubuntu
   uses systemd now so this isn't a way forward for Guix.

I like systemd so I don't have many motivations of anti-systemd people
:)  I'm cool with DMD too, don't really care to be honest.  But logind
interfaces seem to pervade a lot of GNOME, so I'm happy to just take
systemd's implementation and hack it into a standalone thing.

Andy

Re: elogind status

[宋文武]

Andy Wingo <wingo@igalia.com> writes:

> [...]
Great news!

> On Fri 21 Aug 2015 13:48, "Claes Wallin (韋嘉誠)" <gnu@clacke.user.lysator.liu.se> writes:
>
>> How much do you know about what uselessd, nosh and the Ubuntu logind
>> shim and how they did things? I don't know anything, I just know these
>> things exist.
>
> No idea!  Could be some things didn't exist back in May?
>
> Looking now:
>
>  * uselessd is unmaintained, based on an old fork of systemd, actively
>    hates things I don't care about, aims to replace systemd and not just
>    logind
>
>  * nosh: doesn't implement the login1 d-bus interface
>
>  * Ubuntu logind shim: Couldn't find information about this.  Ubuntu
>    uses systemd now so this isn't a way forward for Guix.
AFAIK, "systemd-shim emulates the systemd function", so that Debian/Ubuntu
could run logind(from systemd) without running systemd as init. I think
it's for migration.

Also, I find another attempt 'LoginKit' from Devuan, but it suspended.
<https://github.com/dimkr/LoginKit/issues/11>
>
> I like systemd so I don't have many motivations of anti-systemd people
> :)  I'm cool with DMD too, don't really care to be honest.  But logind
> interfaces seem to pervade a lot of GNOME, so I'm happy to just take
> systemd's implementation and hack it into a standalone thing.
Really cool, I think we can reach GNOME soon :-)

Re: elogind status

[Thompson, David]

On Fri, Aug 21, 2015 at 8:11 AM, Andy Wingo <wingo@igalia.com> wrote:
>
> I like systemd so I don't have many motivations of anti-systemd people
> :)  I'm cool with DMD too, don't really care to be honest.  But logind
> interfaces seem to pervade a lot of GNOME, so I'm happy to just take
> systemd's implementation and hack it into a standalone thing.

I think this is a good strategy.  It will be nice to finally have
GNOME.  I am completely ignorant of how all this stuff fits together
so many, many thanks for working on it.

- Dave

Re: elogind status

[宋文武]

Andy Wingo <wingo@igalia.com> writes:

> Hi :)
>
> [...]
>
> The result is https://github.com/andywingo/elogind.  It provides:
>
>   * a logind-compatible API with a different library name, libelogind
>
>   * a pkg-config file, libelogind.pc
>
>   * a daemon, elogind
>
>   * a PAM module, pam_elogind.so
>
>   * a query/control utility, loginctl
>
> It might be worth it to install more compatibility interfaces for
> systemd, e.g. libsystemd.so, or a symlink for <systemd/sd-login.h> to go
> to <elogind/sd-login.h>.  Or perhaps we should just provide the systemd
> header files with the systemd names.  In practice this means that
> building packages that use the C interfaces need a bit more munging in
> Guix to replace names.
Yeah, as seen in your polkit patch.
>
> In the patches I sent to this list, we have also a service which runs
> elogind, and the facilities to integrate pam_elogind.so with the rest of
> the system.  The PAM integration is really horrible and I'd be
> interested in other options; see footnote for my os-config.scm.
>
> Upstream logind integrates with systemd to ensure that user sessions are
> run in cgroups, which is a pretty neat feature.  They manage cgroups
> with a hierarchical "slice" abstraction.  Perhaps DMD should do this at
> some point.  Using cgroups also lets logind know when a process was
> started by a user but the user has logged out, and optionally lets the
> administrator kill user processes when they log out.  So, elogind will
> expose information about users, sessions, and seats, but for now not
> slices.  Most logind users don't care so this is OK.
Thanks for the detail explaination, maybe we can use cgmanager somehow
later: <https://github.com/lxc/cgmanager>
>
> Andy
>
> [*] Configuring elogind
> [...]
> It's a bit of a cross-cutting concern and I don't know what to do about
> it exactly.  But, with all of this, and the patches I have sent,
> pam_elogind.so does tell logind about users.  I rewired polkit to use
> elogind for console information but I haven't tried going back up the
> stack to get a GNOME session.  Future work, I guess, and help is very
> much welcome :)  If you are interested in hacking on elogind I am sure
> you will find things to do.  Let me know and I'll add you to the
> maintainers.
I follow the config, and get elogind running up.
The pam, seat and session things work,
I can use loginctl or call the dbus method to switch between sessions.
But the reboot and poweroff don't work, which turn out to run the
systemd special target ;-

Re: elogind status

[Andy Wingo]

On Fri 21 Aug 2015 17:19, 宋文武 <iyzsong@gmail.com> writes:

> I follow the config, and get elogind running up.
> The pam, seat and session things work,
> I can use loginctl or call the dbus method to switch between sessions.

Nice!

> But the reboot and poweroff don't work, which turn out to run the
> systemd special target ;-

Yeah I think they call out to systemd's dbus interface.  Same for
suspend and lid handling.  I am not sure what to do there; I would
rather not fake systemd's dbus interface, because that sounds like a
large compatibility headache.  Perhaps we could invoke hooks instead,
and have distros customize those hooks.  Or perhaps we include systemd's
code to do these tasks, if that code is small.

Andy

Re: elogind status

[Thompson, David]

On Fri, Aug 21, 2015 at 11:19 AM, 宋文武 <iyzsong@gmail.com> wrote:
> Andy Wingo <wingo@igalia.com> writes:
>
>> Hi :)
>>
>> [...]
>>
>> The result is https://github.com/andywingo/elogind.  It provides:
>>
>>   * a logind-compatible API with a different library name, libelogind
>>
>>   * a pkg-config file, libelogind.pc
>>
>>   * a daemon, elogind
>>
>>   * a PAM module, pam_elogind.so
>>
>>   * a query/control utility, loginctl
>>
>> It might be worth it to install more compatibility interfaces for
>> systemd, e.g. libsystemd.so, or a symlink for <systemd/sd-login.h> to go
>> to <elogind/sd-login.h>.  Or perhaps we should just provide the systemd
>> header files with the systemd names.  In practice this means that
>> building packages that use the C interfaces need a bit more munging in
>> Guix to replace names.
> Yeah, as seen in your polkit patch.
>>
>> In the patches I sent to this list, we have also a service which runs
>> elogind, and the facilities to integrate pam_elogind.so with the rest of
>> the system.  The PAM integration is really horrible and I'd be
>> interested in other options; see footnote for my os-config.scm.
>>
>> Upstream logind integrates with systemd to ensure that user sessions are
>> run in cgroups, which is a pretty neat feature.  They manage cgroups
>> with a hierarchical "slice" abstraction.  Perhaps DMD should do this at
>> some point.  Using cgroups also lets logind know when a process was
>> started by a user but the user has logged out, and optionally lets the
>> administrator kill user processes when they log out.  So, elogind will
>> expose information about users, sessions, and seats, but for now not
>> slices.  Most logind users don't care so this is OK.

> Thanks for the detail explaination, maybe we can use cgmanager somehow
> later: <https://github.com/lxc/cgmanager>

I think I'm opposed to this.  I say "I think" because I haven't done
all of my homework yet, but I am just starting to write a Scheme
interface to cgroups for use with 'call-with-container' so I've
learned a thing or two.  I'd like to see dmd use cgroups like systemd
does, but I don't think we need to bring in any LXC tools to do it.
All the LXC stuff I've looked at has been too high level to be useful
to us.  Guile has everything we need. :)

- Dave

Re: elogind status

[Andy Wingo]

On Fri 21 Aug 2015 12:33, Andy Wingo <wingo@igalia.com> writes:

> To pick up a thread from May, I was poking at elogind recently.  A bit
> of recap as to how things got here, then the status.

I will keep this patch stack up to date at wip-pam-elogind.  On that
branch there's an update to a new elogind that includes systemd's code
to suspend/hibernate/hybrid-sleep the system, as well as new code to
implement the poweroff/halt/reboot things.  Am I the first Guix user
whose laptop actually sleeps when I close the lid? :)  It is a pleasant
feeling regardless.

I think elogind is pretty much done.  We need to arrange to give it a
better configuration file via the service I guess, and there's a
circularity with polkit -- loginctl wants to call out to the setuid
polkit helper to authorize it for things -- but we can fix those as time
goes on.  If people want to start packaging GNOME now, I think next on
the list would be making sure that polkit actually works (I'm not sure
that it does now, Mark has some work on a WIP branch too) and then
packaging gnome-session and gnome-shell.  NetworkManager too.  At that
point we're pretty much there, I think.

Andy

Re: elogind status

[Ludovic Courtès]

Hello!

Thanks a lot for the update and explanations... and for the achievement!
It’s wonderful that you were able to address it, while some of us (me)
were staring at the issue fearfully thinking “hmm, this looks hard.”
;-)

Andy Wingo <wingo@igalia.com> skribis:

> Upstream logind integrates with systemd to ensure that user sessions are
> run in cgroups, which is a pretty neat feature.  They manage cgroups
> with a hierarchical "slice" abstraction.  Perhaps DMD should do this at
> some point.  Using cgroups also lets logind know when a process was
> started by a user but the user has logged out, and optionally lets the
> administrator kill user processes when they log out.  So, elogind will
> expose information about users, sessions, and seats, but for now not
> slices.  Most logind users don't care so this is OK.

Sounds OK, indeed.  We should indeed add similar cgroup support indeed;
not sure if dmd is the right place, though.

> First of all you need some extra file systems.  These paths provide a
> documented interface to logind information:
>
>   (file-system
>     (device "systemd")
>     (mount-point "/run/systemd")
>     (type "tmpfs")
>     (check? #f)
>     (flags '(no-suid no-dev no-exec))
>     (options "mode=0755")
>     (create-mount-point? #t))
>   (file-system
>     (device "systemd")
>     (mount-point "/run/user")
>     (type "tmpfs")
>     (check? #f)
>     (flags '(no-suid no-dev no-exec))
>     (options "mode=0755")
>     (create-mount-point? #t))

We should add them to %base-file-systems or something.

>            (mingetty-service "tty1" #:motd motd #:additional-session-modules (list pam-elogind))

Now I understand; sorry for not reading messages in the right order!

So I think %desktop-services should map over %base-services and simply
add the session module, as I suggested in the other thread.  WDYT?

If the user adds another login-capable service and forgets to add the
‘pam-elogind’ PAM service in there, there’s a problem, but maybe that’s
acceptable as a first step?

Anyway, thanks for working on this!

Ludo’.

Re: elogind status

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> I will keep this patch stack up to date at wip-pam-elogind.  On that
> branch there's an update to a new elogind that includes systemd's code
> to suspend/hibernate/hybrid-sleep the system, as well as new code to
> implement the poweroff/halt/reboot things.

How does poweroff/halt/reboot works?

On GuixSD, ‘halt’ & co. make an RPC to dmd so that it terminates all the
services (including file system mounts) in the right order.

Anyway, good stuff!

Ludo’.

Re: elogind status

[Andy Wingo]

On Thu 27 Aug 2015 15:25, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@igalia.com> skribis:
>
>> I will keep this patch stack up to date at wip-pam-elogind.  On that
>> branch there's an update to a new elogind that includes systemd's code
>> to suspend/hibernate/hybrid-sleep the system, as well as new code to
>> implement the poweroff/halt/reboot things.
>
> How does poweroff/halt/reboot works?
>
> On GuixSD, ‘halt’ & co. make an RPC to dmd so that it terminates all the
> services (including file system mounts) in the right order.
>
> Anyway, good stuff!

Currently poweroff and halt both invoke the "halt" executable, whose
full path is captured at build-time if available and otherwise searched
in the path.  In Guix the full path is captured.  Poweroff and halt are
the same on modern systems, aren't they?  Dunno.  Reboot invokes reboot,
captured in the same way, and the same for kexec.  Anyway for Guix this
should do the right thing, no?  It waits for the exec'd program to
return and checks the error code.  I guess the actual halt is async
though of course.

Suspend/hibernate/hybrid-sleep all write to /sys/power/disk and
/sys/power/state.

Andy

Re: elogind status

[Andy Wingo]

On Thu 27 Aug 2015 15:21, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@igalia.com> skribis:
>
>> First of all you need some extra file systems.  These paths provide a
>> documented interface to logind information:
>>
>>   (file-system
>>     (device "systemd")
>>     (mount-point "/run/systemd")
>>     (type "tmpfs")
>>     (check? #f)
>>     (flags '(no-suid no-dev no-exec))
>>     (options "mode=0755")
>>     (create-mount-point? #t))
>>   (file-system
>>     (device "systemd")
>>     (mount-point "/run/user")
>>     (type "tmpfs")
>>     (check? #f)
>>     (flags '(no-suid no-dev no-exec))
>>     (options "mode=0755")
>>     (create-mount-point? #t))
>
> We should add them to %base-file-systems or something.

Could we mount all of /run on a tmpfs?  Maybe that wouldn't work for
some reason.  If it's possible we should do it though.

>>            (mingetty-service "tty1" #:motd motd #:additional-session-modules (list pam-elogind))
>
> Now I understand; sorry for not reading messages in the right order!
>
> So I think %desktop-services should map over %base-services and simply
> add the session module, as I suggested in the other thread.  WDYT?
>
> If the user adds another login-capable service and forgets to add the
> ‘pam-elogind’ PAM service in there, there’s a problem, but maybe that’s
> acceptable as a first step?

I'll give it a go :)

Andy

Re: elogind status

[Andy Wingo]

On Thu 27 Aug 2015 15:58, Andy Wingo <wingo@igalia.com> writes:

> On Thu 27 Aug 2015 15:25, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@igalia.com> skribis:
>>
>>> I will keep this patch stack up to date at wip-pam-elogind.  On that
>>> branch there's an update to a new elogind that includes systemd's code
>>> to suspend/hibernate/hybrid-sleep the system, as well as new code to
>>> implement the poweroff/halt/reboot things.
>>
>> How does poweroff/halt/reboot works?
>>
>> On GuixSD, ‘halt’ & co. make an RPC to dmd so that it terminates all the
>> services (including file system mounts) in the right order.
>>
>> Anyway, good stuff!
>
> Currently poweroff and halt both invoke the "halt" executable, whose
> full path is captured at build-time if available and otherwise searched
> in the path.  In Guix the full path is captured.  Poweroff and halt are
> the same on modern systems, aren't they?  Dunno.  Reboot invokes reboot,
> captured in the same way, and the same for kexec.  Anyway for Guix this
> should do the right thing, no?  It waits for the exec'd program to
> return and checks the error code.  I guess the actual halt is async
> though of course.
>
> Suspend/hibernate/hybrid-sleep all write to /sys/power/disk and
> /sys/power/state.

Forgot to add the link.  The suspend code is from systemd, and uses a
config file to configure what to do for various sleep states.  The
halt/reboot/kexec code is mine.  For all of these, upstream systemd does
an RPC to systemd to run special units or targets.  The sleep code ends
up being the same but the halt code is different.

   https://github.com/andywingo/elogind/commit/ef2aa93b7a4c742ae74496566344fd71e411fa72
   http://www.freedesktop.org/software/systemd/man/systemd-sleep.conf.html
   http://www.freedesktop.org/software/systemd/man/systemd-sleep.html

Andy

Re: elogind status

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> Could we mount all of /run on a tmpfs?  Maybe that wouldn't work for
> some reason.  If it's possible we should do it though.

We can’t currently because there’s important stuff like
/run/current-system and /run/setuid-programs.

Ludo’.

Re: elogind status

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> On Thu 27 Aug 2015 15:25, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@igalia.com> skribis:
>>
>>> I will keep this patch stack up to date at wip-pam-elogind.  On that
>>> branch there's an update to a new elogind that includes systemd's code
>>> to suspend/hibernate/hybrid-sleep the system, as well as new code to
>>> implement the poweroff/halt/reboot things.
>>
>> How does poweroff/halt/reboot works?
>>
>> On GuixSD, ‘halt’ & co. make an RPC to dmd so that it terminates all the
>> services (including file system mounts) in the right order.
>>
>> Anyway, good stuff!
>
> Currently poweroff and halt both invoke the "halt" executable, whose
> full path is captured at build-time if available and otherwise searched
> in the path.  In Guix the full path is captured.  Poweroff and halt are
> the same on modern systems, aren't they?  Dunno.

I think so.

> Reboot invokes reboot, captured in the same way, and the same for
> kexec.  Anyway for Guix this should do the right thing, no?

Yes, that’s perfect.

> Suspend/hibernate/hybrid-sleep all write to /sys/power/disk and
> /sys/power/state.

Sounds good.

Thanks,
Ludo’.

Re: elogind status

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> Since elogind wants to manage the content of these directories, it has a
> little internal rm-rf helper to clean them when elogind starts up.  But
> that helper is really conservative and doesn't want to remove files on a
> filesystem that's not tmpfs or ramfs, hence these mounts.
>
> Secondly you need to configure a pam-elogind module.
>
>   (define pam-elogind
>     (pam-entry
>      (control "required")
>      (module #~(string-append #$elogind "/lib/security/pam_elogind.so"))))
>
> We add the pam module to the base pam services:
>
>   (pam-services
>    (base-pam-services #:additional-session-modules (list pam-elogind)))

[…]

(See the whole message at
<https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00439.html>.)

It’s been some time, but commit e7ad0d5 finally adds elogind support to
all the PAM sessions.  It does so by extending PAM with a procedure that
adds a session entry with pam_elogind.so to all the PAM service.

This extension mechanism for cross-cutting PAM concerns is implemented
in 12c00bc.

I’ve confirmed that ‘loginctl’ now knows about logged-in users and
seats.  I haven’t check what effect it has on GNOME and Xfce but
feedback would be welcome!

Ludo’.