Well, there are two packages
elogind containing the elogind itself and
elogind-s6 for a service file that just contains lines
/etc/s6/sv/elogind/run#!/usr/bin/execlineb -P
exec /usr/lib/elogind/elogind
As expected, no daemonizing option provided, it shall run without forking. But this encounters a conflict with a dbus service
/usr/share/dbus-1/system-services/org.freedesktop.login1.service# 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=/usr/lib/elogind/elogind --daemon
User=root
That is,
elogind-daemon appears in tasks with parent PID of init with dbus running properly whilst s6 service run script dies due to failed execution of another non-daemonized elogind. Deletion of service file can possibly bring some incompatibilities with software
but I have little idea how software can be dependent on this service or service file. We could somehow alter service file so it will use s6-rc or s6-svc to change state of s6 supervised elogind. How to properly get rid of this dbus service without breaking stuff
if that's possible?
Possibly an elegant solution (in some sense, we still edit the package file directly) is to delegate elogind start up to s6 by editing the dbus service file. Possibly there is a etc-styled alteration configuration possible but I'm about to propose the change of the service file just right into repository. If there is some problem about that, I would like to see a reply.
# 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
# rather than starting elogind daemon
#Exec=/usr/lib/elogind/elogind --daemon
# just use s6 to start the elogind under s6 supervision
Exec=/usr/bin/s6-rc -u change elogind
User=root
Also you would add the elogind to the default bundle if it is not included by default
s6-rc-bundle-update add default elogind
elogind has had the dbus activation feature (aka starting by itself) for ages. In general though, there should be no problem. You just add the elogind service to your default bundle and it starts with your machine. The dbus service shouldn't do anything. Are you saying that there is an issue with that? There should not be at least.
With that said, a valid option be to just delete the dbus service file from the elogind package altogether. I am pretty sure it is the policy of every init to not rely on dbus activation for elogind and to instead just start the daemon on bootup like any other service. It shouldn't actually matter to any random software whether or not the file is there. They just want to use the logind API.
I've just been bitten by this.
D-Bus failed to initialize during boot for whatever reason this time, and I thought
s6-rc -d change dbus && s6-rc -u change dbus would fix that. It seemed to once startx got working, but logind was the only working D-Bus service. Every other service required a manual s6-rc command besides logind. It seemed weird, so I did
s6-rc -u change elogind only to get tons of
elogind[YYYY]: elogind is already running as PID XXXX
messages on my dmesg. PID XXXX is parented to init (i.e. launched as a double-forked/daemonized executable through D-Bus).
This "works" (I'm typing from the broken session), but it's far from ideal as it bypasses the service manager/supervision suite.