Bug#909027: Leaves daemons running after purge

[Simon McVittie]

On Mon, 17 Sep 2018 at 15:36:48 -0400, Jeremy Bicha wrote:
> On Mon, Sep 17, 2018 at 12:47 PM Steve McIntyre <steve at einval.com> wrote:
> > >I appear to have had some of the gvfs packages installed by accident
> > >on my machine, I guess through dependencies. I noticed this a few days
> > >ago and purged them all. I saw no errors when I did that. I noticed
> > >again today that I still have gvfs programs running. This is clearly
> > >not right.
> 
> The gvfs daemon are system user services.

I assume this was meant to say "systemd user services" (that is, services
that are managed by the systemd --user process that runs under your
own uid, as opposed to systemd system services, which are managed by
pid 1). Various other packages install per-user daemons, some of which
are managed by systemd, some of which are not, and many of which can go
either way depending on whether systemd --user is in use.

We've had per-user daemons for a long time, some of them longer than I've
been involved in Debian - prominent examples include ssh-agent, gpg-agent,
configuration synchronization points like dconf and gconf, IPC systems
like D-Bus and CORBA, and sound mixers like pulseaudio, esd and arts.

> These services keep running
> after removal; another example is gpg-agent. All you need to do is log
> out for the services to be stopped.

I don't think Debian has ever had a general solution to terminating
per-user services on remove or purge. The least-bad option I can see
would be to use pkill or killall from the postinst, but that comes with
a serious risk of accidentally terminating processes other than the one
being removed (for example if you'd removed the packaged gvfs services
in order to run your own /usr/local/bin/gvfsd, you'd be upset if the
maintainer script killed that).

Even if we can assume that all interesting per-user daemons are systemd
user services, it's generally considered to be an anti-pattern for a
system-wide operation (removing a package) to reach into user sessions
and do things there. In particular, it can't use D-Bus on the session
bus, because the trust relationships would be wrong: D-Bus clients trust
their dbus-daemon, but maintainer scripts running as root must not trust
a dbus-daemon running as a user.

    smcv