gnome-remote-desktop 46 upstream has decided to implement both
tmpfiles.d and sysusers.d to create a system user and its home
directory. systemd-tmpfiles needs to run before systemd-sysusers. If
not, on a new install, this command hangs for about 90 seconds:

Creating user 'gnome-remote-desktop' (GNOME Remote Desktop) with UID
*** and GID ***.

Then this error:
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 148.

Then the installation completes successfully.

Therefore, I recommend that debhelper automatically runs
dh_installtmpfiles before running dh_installsysusers in case any other
projects want to do what gnome-remote-desktop does.

I was able to workaround this issue:
https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/8490919

Thank you,
Jeremy Bícha

Jeremy Bícha:

Hi Michael and Luca

What is the correct order for tmpfiles vs. sysusers?

I thought the order was sysusers (to create the user) and then tmpfiles
(to create files/directories and set ownership accordingly). In this bug
report, the request is to have the directories first before the user is
created.

Could you please assert what the correct order is for the default case?

Best regards,
Niels

There is a circular dependency here.

$ cat /usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf
# tmpfiles.d file to ensure the existence of the home directory for
gnome-remote-desktop user
d /var/lib/gnome-remote-desktop 0700 gnome-remote-desktop gnome-remote-desktop
d /etc/gnome-remote-desktop 0755 gnome-remote-desktop gnome-remote-desktop

$ cat /usr/lib/sysusers.d/gnome-remote-desktop-sysusers.conf
# sysusers.d file to ensure the existence of the gnome-remote-desktop user
u gnome-remote-desktop - "GNOME Remote Desktop" /var/lib/gnome-remote-desktop

The 90 second hang if systemd-sysusers is run before
/var/lib/gnome-remote-desktop exists is annoying, but systemd-tmpfiles
errors if the gnome-remote-desktop user doesn't exist yet.

Running tmpfiles, then sysusers, then tmpfiles again works except for
that 90 second hang.

I had to remove the gnome-remote-desktop package, then remove the
gnome-remote-desktop user and the directories and then reboot to test
changes properly.

Thank you,
Jeremy Bícha

Am I reading this correctly, that the package is using tmpfiles to
create a home directory? I'm not sure that was foreseen as a use case
to be honest, I'd bring it upstream

Yes. Should I bring the issue upstream to systemd or upstream to
gnome-remote-desktop?

Thank you,
Jeremy Bícha

Actually the manpage of sysusers.d suggests to do this:

systemd-sysusers only sets the home directory record in the user
database. To actually create the directory, consider adding a
corresponding tmpfiles.d(5) fragment.

So please open an issue upstream in the systemd repo with the
reproducer for the race condition, as it sounds something that at
least should be documented explicitly how to handle, at a minimum

The request to run tmpfiles before sysusers seems wrong to me, and I think
it should be wontfix. The directories certainly can't be successfully
created owned by the gnome-remote-desktop user before the user even
exists!

My understanding is that the sequence should be:

1. sysusers: Create user
2. tmpfiles: Create home directory owned by that user
3. systemctl daemon-reload
4. Start system services that run as that user

And if there are any systemd *user* services that rely on the tmpfiles
snippet, they will also need to be set up no earlier than step 3.

It looks as though debhelper itself, in a sufficiently new compat level,
gets this right:

	$include_if_compat_X_or_newer->(14, 'dh_installsysusers'),
	$include_if_compat_X_or_newer->(13, 'dh_installtmpfiles'),
	$include_if_compat_X_or_newer->(11, 'dh_installsystemd'),
	$include_if_compat_X_or_newer->(12, 'dh_installsystemduser'),

In older compat levels, opting-in to dh-sequence-installsysusers triggers
somewhat earlier:

insert_after('dh_install', 'dh_installsysusers');

but that seems like it should be fine too: the important thing is that
we get sysusers -> tmpfiles -> systemd{,user} in that order.

I think the *actual* bug here is that gnome-remote-desktop installs a
D-Bus policy fragment to allow the gnome-remote-desktop user to own the
org.gnome.RemoteDesktop name, but the postinst does not ensure that
the D-Bus system message bus (dbus-daemon or dbus-broker) has reloaded
its configuration before attempting to start gnome-remote-desktop.
I'll follow up to #1070119 with more details since this is not a
debhelper problem.

    smcv

Simon McVittie:
 >

Thanks for the feedback. Having read the follow up #1072698, I think we
have a feature request for debhelper which is to support this
interaction between sysusers, tmpfiles, dbus reloading, and (then)
starting the service. Renamed bug accordingly.

Best regards,
Niels