Bug#764678: dh-systemd: Please support systemd user services

[Daniele Nicolodi]

On 10/09/2018 09:07, Michael Biebl wrote:
> Am 10.09.18 um 16:47 schrieb Daniel Kahn Gillmor:
>> On Mon 2018-09-10 14:07:44 +0100, Simon McVittie wrote:
>>> It might be a reasonable middle ground for sockets and other
>>> auto-activation mechanisms to be statically enabled on the user bus, so
>>> that the services are not started eagerly, but are started on-demand?
>>
>> For the record, this is what the gpg-agent and dirmngr packages do.  It
>> would be great if it was well-supported by dh-systemd, instead of being
>> done manually in debian/dirmngr.links and debian/gpg-agent.links.
> 
> Work is being done on dh_installsystemduser
> Some bits have already landed in init-system-helpers [1] and there is an
> open MR for debhelper [2].
> Once that MR lands in debhelper, picking a package like gpg-agent and
> converting it to the new helper might be a good idea to give it some
> real world testing and shake out any bugs.
> 
> CCed Daniele, as he's been the one driving this effort.

Hello all,

I just found the time to rebase the debhelper patch [1]. It should be
ready to be merged now. As soon as a debhlper version with the patch
incorporated is release I will re-upload my dbus-broker package to
mentors.d.n to give the thing some real world exposure.

[1] https://salsa.debian.org/debian/debhelper/merge_requests/5

Cheers,
Dan

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

> Work is being done on dh_installsystemduser
> Some bits have already landed in init-system-helpers [1] and there is an
> open MR for debhelper [2].
> Once that MR lands in debhelper, picking a package like gpg-agent and
> converting it to the new helper might be a good idea to give it some
> real world testing and shake out any bugs.

thanks!  I'm reading this bug report, so feedback here would be great.
or feel free to let me know via a report in the BTS for either gpg-agent
or dirmngr and i'll wrap it up that way.

the ongoing work on debhelper is much appreciated!

--dkg

Bug#764678: dh-systemd: Please support systemd user services

[Michael Biebl]

Am 10.09.18 um 16:47 schrieb Daniel Kahn Gillmor:
> On Mon 2018-09-10 14:07:44 +0100, Simon McVittie wrote:
>> It might be a reasonable middle ground for sockets and other
>> auto-activation mechanisms to be statically enabled on the user bus, so
>> that the services are not started eagerly, but are started on-demand?
> 
> For the record, this is what the gpg-agent and dirmngr packages do.  It
> would be great if it was well-supported by dh-systemd, instead of being
> done manually in debian/dirmngr.links and debian/gpg-agent.links.

Work is being done on dh_installsystemduser
Some bits have already landed in init-system-helpers [1] and there is an
open MR for debhelper [2].
Once that MR lands in debhelper, picking a package like gpg-agent and
converting it to the new helper might be a good idea to give it some
real world testing and shake out any bugs.

CCed Daniele, as he's been the one driving this effort.

Regards,
Michael

[1] https://salsa.debian.org/debian/init-system-helpers/merge_requests/1
[2] https://salsa.debian.org/debian/debhelper/merge_requests/5

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

On Mon 2018-09-10 14:07:44 +0100, Simon McVittie wrote:
> It might be a reasonable middle ground for sockets and other
> auto-activation mechanisms to be statically enabled on the user bus, so
> that the services are not started eagerly, but are started on-demand?

For the record, this is what the gpg-agent and dirmngr packages do.  It
would be great if it was well-supported by dh-systemd, instead of being
done manually in debian/dirmngr.links and debian/gpg-agent.links.

Regards,

--dkg

Bug#764678: dh-systemd: Please support systemd user services

[Simon McVittie]

On Thu, 24 Nov 2016 at 17:35:58 +0100, Michael Biebl wrote:
> See for example dbus-user-session, which ships
> 
> /usr/lib/systemd/user/dbus.service
> /usr/lib/systemd/user/dbus.socket
> and
> /usr/lib/systemd/user/sockets.target.wants/dbus.socket

Note that dbus is special: it is statically enabled by upstream, in
consultation with systemd upstream, because systemd --user itself benefits
from having access to a dbus-daemon. This is not the case for ordinary
user-services like pulseaudio, gnupg, gnome-settings-daemon and similar,
so should not necessarily be taken as precedent.

"Statically enabled" is jargon for units that do not have an [Install]
section, just a "hard-coded" symlink in /usr or /lib. They can't be
disabled, but they can still be masked, assuming you are willing to keep
both pieces if the system breaks as a result.

Similarly, the system dbus-daemon is statically enabled on the system bus,
unlike most "normal" system services, because systemd-as-pid-1 wants to
use it for systemctl and polkit (when installed).

It might be a reasonable middle ground for sockets and other
auto-activation mechanisms to be statically enabled on the user bus, so
that the services are not started eagerly, but are started on-demand?

Many systemd user services are D-Bus-activatable, and D-Bus .service files
are like having a statically enabled .socket unit (or more precisely,
a statically enabled .busname unit, in the alternate reality where
kdbus happened) - they do not have a concept of disabled state, but are
always willing to launch the referenced D-Bus service, either directly or
via systemd, when it is contacted.

smcv

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

On Wed 2016-12-21 03:49:08 -0500, Michael Biebl wrote:
> My earlier comment [1], that shipping the symlink in the package is
> ugly, was specifically meant for doing it in /etc.
> Shipping the symlinks in /usr/lib/systemd/user/foo.wants/ is imho an
> acceptable solution for stretch, i.e.
> /usr/lib/systemd/user/sockets.target.wants/gpg-agent.socket

yeah, i think we should be enabling the socket units but not the
.service units.

> I'm not sure if gpg-agent-ssh.socket and gpg-agent-extra.socket should
> be enabled by default. Those look like they should be enabled on a
> per-user basis and default to off?

in upstream gpg they default to being on anyway (as of 2.1.15, iirc), so
i'm going to ship them enabled, i think.

> In buster we should definitely add proper support for user services to
> i-s-h and dh-systemd. For stretch this is too late and not going to
> happen (anymore). Sorry about that.

no worries, and thanks for the followup!

   --dkg


signature.asc
Description: PGP signature

Bug#764678: dh-systemd: Please support systemd user services

[Michael Biebl]

Am 24.11.2016 um 17:35 schrieb Michael Biebl:
> Am 23.11.2016 um 16:00 schrieb Daniel Kahn Gillmor:
>> On Mon 2016-10-31 15:49:29 -0400, Daniel Kahn Gillmor wrote:

>> Sorry to nag about this, but is there any alternative to my just
>> shipping symlinks?
> 
> Are those user services supposed to be enabled by default?
> If so, I'd just ship the symlinks in the package for now.
> 
> See for example dbus-user-session, which ships
> 
> /usr/lib/systemd/user/dbus.service
> /usr/lib/systemd/user/dbus.socket
> and
> /usr/lib/systemd/user/sockets.target.wants/dbus.socket

My earlier comment [1], that shipping the symlink in the package is
ugly, was specifically meant for doing it in /etc.
Shipping the symlinks in /usr/lib/systemd/user/foo.wants/ is imho an
acceptable solution for stretch, i.e.
/usr/lib/systemd/user/sockets.target.wants/gpg-agent.socket

I'm not sure if gpg-agent-ssh.socket and gpg-agent-extra.socket should
be enabled by default. Those look like they should be enabled on a
per-user basis and default to off?

In buster we should definitely add proper support for user services to
i-s-h and dh-systemd. For stretch this is too late and not going to
happen (anymore). Sorry about that.

Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678#15
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#764678: dh-systemd: Please support systemd user services

[Michael Biebl]

Am 23.11.2016 um 16:00 schrieb Daniel Kahn Gillmor:
> On Mon 2016-10-31 15:49:29 -0400, Daniel Kahn Gillmor wrote:
>> Is there any word on this?  GnuPG upstream has now merged patches to
>> support socket-activation of dirmngr and gpg-agent, and gnupg2 version
>> 2.1.15-8 has .service and .socket files for managing nice clean
>> user-level services.
>>
>> I don't plan on enabling them globally right away (i'd love to hear more
>> feedback from users who have enabled them manually), but i'd really like
>> to be *able* to enable them in the package if we decide that makes
>> sense.
>>
>> In the event that globally-enabling seems warranted, if there is no
>> explicit support by dh-systemd or any better alternatives, i'm likely to
>> resort to shipping symlinks in /etc/systemd/user/ :/ any other
>> suggestions?
> 
> Sorry to nag about this, but is there any alternative to my just
> shipping symlinks?

Are those user services supposed to be enabled by default?
If so, I'd just ship the symlinks in the package for now.

See for example dbus-user-session, which ships

/usr/lib/systemd/user/dbus.service
/usr/lib/systemd/user/dbus.socket
and
/usr/lib/systemd/user/sockets.target.wants/dbus.socket


Sorry I don't have a better answer atm.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

On Mon 2016-10-31 15:49:29 -0400, Daniel Kahn Gillmor wrote:
> Is there any word on this?  GnuPG upstream has now merged patches to
> support socket-activation of dirmngr and gpg-agent, and gnupg2 version
> 2.1.15-8 has .service and .socket files for managing nice clean
> user-level services.
>
> I don't plan on enabling them globally right away (i'd love to hear more
> feedback from users who have enabled them manually), but i'd really like
> to be *able* to enable them in the package if we decide that makes
> sense.
>
> In the event that globally-enabling seems warranted, if there is no
> explicit support by dh-systemd or any better alternatives, i'm likely to
> resort to shipping symlinks in /etc/systemd/user/ :/ any other
> suggestions?

Sorry to nag about this, but is there any alternative to my just
shipping symlinks?

 --dkg


signature.asc
Description: PGP signature

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

On Wed 2016-08-10 01:50:58 -0400, Daniel Kahn Gillmor wrote:
> Control: affects 764678 + dirmngr gnupg-agent pulseaudio
>
> On Fri 2016-08-05 12:38:58 -0400, Daniel Kahn Gillmor wrote:
>> On Tue 2016-06-28 19:39:26 -0400, Michael Biebl wrote:
>>> Daniel, which service do you have in mind which already requires a
>>> systemd user session and systemd user services?
>>
>> i'm looking at this for the gnupg-agent and dirmngr packages
>> (gpg-agent.service and dirmngr.service), which are currently generated
>> From the gnupg2 source package in experimental.
>
> fwiw, i think that the pulseaudio user service would also be a good idea
> to enable automatically.

Is there any word on this?  GnuPG upstream has now merged patches to
support socket-activation of dirmngr and gpg-agent, and gnupg2 version
2.1.15-8 has .service and .socket files for managing nice clean
user-level services.

I don't plan on enabling them globally right away (i'd love to hear more
feedback from users who have enabled them manually), but i'd really like
to be *able* to enable them in the package if we decide that makes
sense.

In the event that globally-enabling seems warranted, if there is no
explicit support by dh-systemd or any better alternatives, i'm likely to
resort to shipping symlinks in /etc/systemd/user/ :/ any other
suggestions?

  --dkg


signature.asc
Description: PGP signature

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

Control: affects 764678 + dirmngr gnupg-agent pulseaudio

On Fri 2016-08-05 12:38:58 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2016-06-28 19:39:26 -0400, Michael Biebl wrote:
>> Daniel, which service do you have in mind which already requires a
>> systemd user session and systemd user services?
>
> i'm looking at this for the gnupg-agent and dirmngr packages
> (gpg-agent.service and dirmngr.service), which are currently generated
> From the gnupg2 source package in experimental.

fwiw, i think that the pulseaudio user service would also be a good idea
to enable automatically.

Currently, on a testing system with a stock gnome-core 1:3.20+1
installed, without the pulseaudio user service being enabled, a user
session will persist up to 20 seconds after logout is complete, waiting
on "/usr/bin/pulseaudio --start --log-target=syslog" to terminate.

the 20 seconds comes from pulse's "--exit-idle-time" default:

 
https://sources.debian.net/src/pulseaudio/8.0-2/src/daemon/daemon-conf.c/?hl=72#L61

if the user does:

 systemctl --user enable pulseaudio

and then logs out, waits at least 20 seconds, and logs back in again,
then her new pulse server will be managed by the systemd user services
(user@.service in the cgroup hierarchy shown by "systemctl status")
instead of in the specific login session (session-N.scope).

Subsequent logouts no longer wait for pulseaudio to terminate.

On machines running systemd, a user service seems like a cleaner way to
supervise pulseaudio.

   --dkg


signature.asc
Description: PGP signature

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

On Tue 2016-06-28 19:39:26 -0400, Michael Biebl wrote:
> Am 29.06.2016 um 00:11 schrieb Daniel Kahn Gillmor:
>> On Fri 2014-10-10 03:30:07 -0400, Michael Vogt  wrote:
>>> It would be very nice if dh-systemd would support systemd user
>>> units (both for detecting them during build time and to add
>>> something like "systemctl --global enable my-user-unit" to the
>>> debian/postinst).
>>>
>>> My use case is that the package installs a unit that
>>> should run at login time for all users. In the past this was 
>>> done via the upstart session support. 
>> 
>> fwiw, i'd like to see this capability for dh-systemd as well.
>> 
>> One alternative available now is to have the package manually ship a
>> symlink in /etc/systemd/user/default.target.wants/$PKGNAME.service
>> (pointing to /usr/lib/systemd/user/$PKGNAME.service, assuming the user
>
> Shipping a static symlink in /etc is ugly, I would recommend against
> doing that.
>
> Daniel, which service do you have in mind which already requires a
> systemd user session and systemd user services?

i'm looking at this for the gnupg-agent and dirmngr packages
(gpg-agent.service and dirmngr.service), which are currently generated
From the gnupg2 source package in experimental.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#764678: dh-systemd: Please support systemd user services

[Michael Biebl]

Am 29.06.2016 um 00:11 schrieb Daniel Kahn Gillmor:
> On Fri 2014-10-10 03:30:07 -0400, Michael Vogt  wrote:
>> It would be very nice if dh-systemd would support systemd user
>> units (both for detecting them during build time and to add
>> something like "systemctl --global enable my-user-unit" to the
>> debian/postinst).
>>
>> My use case is that the package installs a unit that
>> should run at login time for all users. In the past this was 
>> done via the upstart session support. 
> 
> fwiw, i'd like to see this capability for dh-systemd as well.
> 
> One alternative available now is to have the package manually ship a
> symlink in /etc/systemd/user/default.target.wants/$PKGNAME.service
> (pointing to /usr/lib/systemd/user/$PKGNAME.service, assuming the user

Shipping a static symlink in /etc is ugly, I would recommend against
doing that.

Daniel, which service do you have in mind which already requires a
systemd user session and systemd user services?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#764678: dh-systemd: Please support systemd user services

[Daniel Kahn Gillmor]

On Fri 2014-10-10 03:30:07 -0400, Michael Vogt  wrote:
> It would be very nice if dh-systemd would support systemd user
> units (both for detecting them during build time and to add
> something like "systemctl --global enable my-user-unit" to the
> debian/postinst).
>
> My use case is that the package installs a unit that
> should run at login time for all users. In the past this was 
> done via the upstart session support. 

fwiw, i'd like to see this capability for dh-systemd as well.

One alternative available now is to have the package manually ship a
symlink in /etc/systemd/user/default.target.wants/$PKGNAME.service
(pointing to /usr/lib/systemd/user/$PKGNAME.service, assuming the user
service wants to be installed in default.target), but shipping this
symlink as a config file seems a little bit strange, and wouldn't be
safely undoable by "systemctl --global disable my-user-unit" (it'd just
get re-added on upgrade, i think).

It'd be nice to have something more generalized, which can be safely and
cleanly overridden by both the admin and by individual users.

--dkg


signature.asc
Description: PGP signature

Bug#764678: dh-systemd: Please support systemd user services

[Michael Vogt]

Package: dh-systemd
Severity: wishlist

It would be very nice if dh-systemd would support systemd user
units (both for detecting them during build time and to add
something like systemctl --global enable my-user-unit to the
debian/postinst).

My use case is that the package installs a unit that
should run at login time for all users. In the past this was 
done via the upstart session support. 

If you agree with the general idea I can help and work on a
patch.

Thanks,
 Michael


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org