Bug#1070119: gnome-remote-desktop: long delay when first installing version 46.1-2, odd workaround in 46.1-3

[Simon McVittie]

On Wed, 15 May 2024 at 09:52:53 +0200, Jeremy Bícha wrote:
> I'm not happy with the performance of what I've implemented because it
> still has the 90 second delay even though gnome-remote-desktop is
> otherwise working now.

I don't think this is a debhelper or systemd bug.
I am able to reproduce it by building gnome-remote-desktop from
<https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/merge_requests/7>,
which I believe is functionally equivalent to 46.1-2 (without the
workaround of invoking sysusers and tmpfiles in the opposite order as
was done in 46.1-3, which I think is the wrong workaround and I'm honestly
not sure why it would even help).

After reproducing the issue, I can re-reproduce it like this:

sudo systemctl stop gnome-remote-desktop
sudo deluser gnome-remote-desktop
sudo rm -fr /etc/gnome-remote-desktop /var/lib/gnome-remote-desktop
sudo dpkg-reconfigure gnome-remote-desktop

If I hack /lib/systemd/system/gnome-remote-desktop.service to have
"ExecStart=/usr/bin/env G_MESSAGES_DEBUG=all ...", then I can see output
from g-r-d, indicating that systemd has successfully executed the daemon
as the target user (in other words, probably not a systemd bug). However,
the daemon fails to acquire its name on the system bus. This made me think:
what is/should be giving it permission to own that name?

The answer is that it installs a D-Bus policy fragment to allow the g-r-d
user to own the intended name. dbus has an "interest-noawait" on the
directory containing policy fragments, which is sufficient for subsequent
on-demand activation of D-Bus services, but is not sufficient to ensure
that a system service that needs to own a bus name can be run immediately
from the postinst of a package that is configured during the same apt
transaction that created the system user!

However, an "interest-await" would happen too soon: it would reload the
bus policy before gnome-remote-desktop.postinst is allowed to run, but
at that point the gnome-remote-desktop uid wouldn't exist yet, so the
policy would have to be skipped.

So I think a correct invocation sequence would go something like this:

1. sysusers: Create user
2. tmpfiles: Create home directory owned by that user
3. invoke-rc.d dbus reload, as is done in polkitd.postinst
   (or busctl call org.freedesktop.DBus /org/freedesktop/DBus \
   org.freedesktop.DBus ReloadConfig)
   (or the equivalent with dbus-send, see dbus.postinst)
4. systemctl daemon-reload
5. Start system services that run as that user

Strictly speaking the partial order is: 1 < 2 < 5, 1 < 3 < 5, 1 < 4 < 5
but steps 2, 3, 4 can be arbitrarily parallelized, I think.

polkitd currently achieves this by not using the sysusers sequence, and
instead invoking sysusers and `invoke-rc.d dbus reload` before #DEBHELPER#.

It might be better if there was a way to ask debhelper to insert the
`invoke-rc.d dbus reload` into the generated part of the postinst, such
that it will be done in the appropriate sequence.

    smcv