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
