Skip to main content ↑ ↓
Topic: Both elogind and elogind-s6 provide service files for dbus and s6 respectively (Read 990 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Both elogind and elogind-s6 provide service files for dbus and s6 respectively

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
Code: [Select]
#!/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
Code: [Select]
#  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?

Re: Both elogind and elogind-s6 provide service files for dbus and s6 respectively

Reply #1 –
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.
Code: [Select]
#  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
Code: [Select]
s6-rc-bundle-update add default elogind

Re: Both elogind and elogind-s6 provide service files for dbus and s6 respectively

Reply #2 –
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.
 

Re: Both elogind and elogind-s6 provide service files for dbus and s6 respectively

Reply #3 –
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

Code: [Select]
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.