I have two small issues with the service file

1) The current service file for autofs on buster sets

       PIDFile=/var/run/autofs.pid

   I saw that it is changed to

       PIDFile=/run/autofs.pid

   on salsa, which is great, but ExecStart still sets

The current upstream version of autofs provides a sample service file that for
Debian would look like this

It would be great if you could change the service file to this. While those
options are not documented in the man page, they are visible in the help output
of the automount command.

Changing the service file would make the service more robust.

Hi Jörg,

thanks for your contribution. To make an update possible for Debian
bullseye (we are in deep freeze), I need a more dramatic description
of things that might go wrong with the current .service file.

Please explain the opposite of "robust" with concrete observations
(i.e. bugs).

Furthermore, have you tested the proposed service file with
autofs-ldap??? With autofs-ldap we still have a nasty race condition
that leaves autofs non-function if it starts before nslcd (libnss LDAP
caching daemon).

Thanks+Greets,
Mike

experienced any issues in that regard.

I'm currently debugging a race condition with another service that only depends
on autofs where a single autofs mountpoint doesn't work but all the others (all
backed via LDAP) are. The service in question usually starts at the same second
as autofs. Since notify will notify readiness when the service thinks it's ready
instead of at fork time, my hope is that it will go away if autofs is actually
ready, when it is shown as such. Just spitballing here, but maybe that's
the issue with nslcd for you, too? Unfortunately nslcd doesn't doesn't have
notification support, but I once worked around a similar issue with autofs data
in NIS by busy looping in ExecStartPre= until NIS was actually
working. Fortunately, with sssd this was no longer an issue. :)

And as a nit: the /var/run path was a log nuisance for a long time and the only
reason this has stopped, is because the systemd package now carries a patch to
silence the warning, because it was apparently easier to do that than fix the
service files all over Debian.

Since the autofs package is built without --with-systemd, the above service file
cannot be used out of the box. I'll rebuild autofs for my machines and will let
you know whether it fixes my issue, but even if it doesn't it would be a
positive change for all people using autofs on systemd.

I completely understand that this probably can't make it into bullseye, but
maybe for bookworm we can use the service file, that upstream has been shipping
since end of October 2018. :)

So my race condition doesn't seem to be because of autofs not signalling
readiness itself, since my problem still occurs with systemd support
enabled in autofs and, as I noticed, also well after boot.

Still, building autofs with systemd support would be nice to have in
bookworm. It's time. :) Upstream also supplies a service file in their
samples, so that can be used. In that case the init script is not
installed, so as long as people want to have that, it needs to be added
manually (in override_dh_auto_install I guess).