Systemd user instance equivalent of dh_systemd_enable?
Hello, I'm working on a package that installs a systemd user instance unit file that needs to be enabled with # systemctl --global enable foo.service Using debhelper, dh_systemd_enable takes care of this automatically for system unit files, but not for user unit files. Is there some other (semi)automatic way of doing it or should I take care of it manually in the postinst and prerm maintainer scripts? Thanks! Cheers, Dan
Re: Systemd user instance equivalent of dh_systemd_enable?
Hi Daniele, * Daniele Nicolodi [2018-04-07 18:18]: I'm working on a package that installs a systemd user instance unit file that needs to be enabled with # systemctl --global enable foo.service Using debhelper, dh_systemd_enable takes care of this automatically for system unit files, but not for user unit files. Is there some other (semi)automatic way of doing it or should I take care of it manually in the postinst and prerm maintainer scripts? I use User= in the [Service] section of the service file for that. Cheers Jochen signature.asc Description: PGP signature
Re: Systemd user instance equivalent of dh_systemd_enable?
On Sat, 07 Apr 2018 at 18:18:11 -0600, Daniele Nicolodi wrote:
> I'm working on a package that installs a systemd user instance unit file
> that needs to be enabled with
>
> # systemctl --global enable foo.service
I believe the only way to do this is currently to make
it be statically enabled for all users (ship a symlink in
/usr/lib/systemd/user/${something}.wants).
What is the package?
Is it something that all users are going to want?
Is it something that makes sense to run every time any user logs in in
any way (ssh, console login, graphical login) or only on entry to a
graphical session?
Would it make sense to arrange for it to be socket-activated (like
dbus-user-session, gpg-agent, pulseaudio) or D-Bus-activated (like
gnome-terminal-server) or autostarted on login to a graphical session (via
/etc/xdg/autostart), rather than being started eagerly on every login?
(The way packages like dbus-user-session, gpg-agent and pulseaudio set
themselves up for socket activation is to have their *.socket unit be
statically enabled in sockets.target, but not their *.service unit in
default.target.)
smcv
Re: Systemd user instance equivalent of dh_systemd_enable?
On 08/04/2018 05:28, Simon McVittie wrote:
> On Sat, 07 Apr 2018 at 18:18:11 -0600, Daniele Nicolodi wrote:
>> I'm working on a package that installs a systemd user instance unit file
>> that needs to be enabled with
>>
>> # systemctl --global enable foo.service
>
> I believe the only way to do this is currently to make
> it be statically enabled for all users (ship a symlink in
> /usr/lib/systemd/user/${something}.wants).
>
> What is the package?
>
> Is it something that all users are going to want?>
> Is it something that makes sense to run every time any user logs in in
> any way (ssh, console login, graphical login) or only on entry to a
> graphical session?
>
> Would it make sense to arrange for it to be socket-activated (like
> dbus-user-session, gpg-agent, pulseaudio) or D-Bus-activated (like
> gnome-terminal-server) or autostarted on login to a graphical session (via
> /etc/xdg/autostart), rather than being started eagerly on every login?
>
> (The way packages like dbus-user-session, gpg-agent and pulseaudio set
> themselves up for socket activation is to have their *.socket unit be
> statically enabled in sockets.target, but not their *.service unit in
> default.target.)
Hi Simon,
the package is dbus-broker, a replacement for dbus-deamon. You may have
heard of it: there has been a short exchange about its packaging for
Debian with its developers with the Debian dbus maintainers in Cc.
dbus-broker ships an user instance unit file with this Install section:
[Install]
Alias=dbus.service
with
# systemctl --global enable foo.service
a /etc/systemd/user/dbus.service symlink is created that overrides the
unit installed by dbus-daemon obtaining that dbus-broker "takes over"
the bus activation units installed by dbus-daemon. A similar thing is
done for the system bus, but that is taken care of by dh_systemd_enable
just fine.
I can create the link manually.
Cheers,
Dan
Re: Systemd user instance equivalent of dh_systemd_enable?
On Sun, 08 Apr 2018 at 08:26:13 -0600, Daniele Nicolodi wrote: > the package is dbus-broker, a replacement for dbus-deamon. You may have > heard of it: there has been a short exchange about its packaging for > Debian with its developers with the Debian dbus maintainers in Cc. Sorry, I didn't see that conversation until now. Please use the role address @packages.debian.org if you want to reach package maintainers: mailing lists used to represent team maintenance often don't have the entire team subscribed, particularly if the team maintains many not-entirely-related packages (as pkg-utopia does), because the list receives all the "messages to the maintainer" for every package that it maintains, making it inconveniently high-traffic. If dbus-broker is uploaded to Debian as an optional dbus-daemon replacement, it will definitely need to be coordinated with the dbus source package. Having the two packages coexist is probably not going to be straightforward to set up, and if any diversions, alternatives etc. are going on, all maintainers of the dbus package will need to be aware of them. I do not expect that dbus-broker will be compatible with every D-Bus service in Debian. The one incompatibility that I'm reasonably sure exists is that if the Exec= for an activatable service points to a command that will fork (background itself) and exit 0, dbus-daemon tolerates this (at the cost of worse error behaviour because it cannot tell whether the service subsequently fails), while dbus-broker almost certainly does not. This is inadvisable behaviour even with the reference dbus-daemon, so I'd consider it to be a bug in the service, but unfortunately it can't be detected statically. It's unfortunate that current Debian infrastructure conflates the concepts of "should receive every communication about all of these packages" and "is a team": hopefully current/near-future work being done on tracker.debian.org will address that. smcv
