[PATCH][WIP] Elogind update

[Stefan Stefanović]

Hello,
Guix.

As I announced, here is patch that let's us update elogind.
Note: This patch is work in progress.
 Please do not mind the lack of proper commit message.
 Since I expect more changes to this patch, I did not bother writing it.

As I far as I know, the last work on elogind is by Marius Bakke:
https://lists.gnu.org/archive/html/guix-patches/2018-01/msg00053.html

The main reason why we did not update to newer versions of elogind is
because system randomly failed to boot after power-off or reboot.

Problem: elogind service fails to start after reboot.

This issue started after elogind introduced ELOGIND_PID_FILE,
"/run/elogind.pid" or in our case "/var/run/elogind.pid", with the commits:

[7c401f91ca900a8ddb2718cbdf7c18dddbe69d59
 Prep v231.6: Allow elogind to be daemonized using -D/--daemon option]
[132565d5bc5f179532fe56c08abbba979e342a35
 Prep v235: Allow elogind to daemonize itself with "-D|--daemon".]

Version v232.4 didn't include the above problematic commits.
Version v234.3 included 7c401f91ca900a8ddb2718cbdf7c18dddbe69d59.

Thanks to the awesome work of current Elogind maintainer Yamakuzure (Sven)
the problem is mostly solved.
Please take a look at GitHub issue: https://github.com/elogind/elogind/issues/94
it will explain the problem better than I could.

The next release will contain the 1st part of the solution.
The installation of the signal handlers is fixed. PID file is deleted,
when system powers-off.

But the problem is with the stale PID found after a forced/abrupt reboot.
As far as I know other distributions do not have to deal with this problem,
because they mount tmpfs to /run and /var/run.
We (Guix) need to find the 2nd part of the solution.

WARNING: If you use the provided elogind-next patch please note that
you may need to manually delete stale PID file "/var/run/elogind.pid",
only in the special/rare case of forced/abrupt reboot.
Failure to do so will prevent elogind and your system from starting!

One thing that I noticed while testing other versions of elogind:
If I run:
 sudo herd disable elogind
 sudo herd stop elogind
the service is re-started by DBus daemon.
but the status of elogind remains:
Status of elogind:
  It is stopped.
  It is disabled.
It seams that Shepherd does not check/detect
if the process is stopped or running.
Is this a bug?
How should Shepherd deal/interact with DBus daemon
since they both start services?
How Should we deal with services started with user level privileges,
possibly by user DBus session daemon
(for example notification service or pulseaudio service)?

If you have time please test this update, and/or comment.
Do not forget to modify your desktop services to use elogind-next:
(modify-services
    %desktop-services
    (elogind-service-type config =>
        (elogind-configuration
            (inherit config)
            (elogind elogind-next)))
;; other modifications...
)

If we find solution for the second part of the problem
we could update elogind after next release v239.2,
which should be out by the end of the next week.

Stefan.

0001-gnu-Add-elogind-next.v2.patch
Description: Text Data