Bug#960676: autofs: update service file
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). OpenPGP_signature Description: OpenPGP digital signature
Bug#960676: autofs: update service file
Hi Jörg, On Di 15 Jun 2021 10:47:53 CEST, Jörg Behrmann wrote: Package: autofs Version: 5.1.7-1 Followup-For: Bug #960676 The current upstream version of autofs provides a sample service file that for Debian would look like this [Unit] Description=Automounts filesystems on demand After=network.target ypbind.service sssd.service network-online.target remote-fs.target rpc-statd.service rpcbind.service Wants=network-online.target rpc-statd.service rpcbind.service [Service] Type=notify EnvironmentFile=-/etc/default/autofs ExecStart=/usr/sbin/automount $OPTIONS --systemd-service --dont-check-daemon ExecReload=/usr/bin/kill -HUP $MAINPID KillMode=process TimeoutSec=180 [Install] WantedBy=multi-user.targe 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. 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 -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpK795q3XBk2.pgp Description: Digitale PGP-Signatur
Bug#960676: autofs: update service file
On Tue, Jun 15, 2021 at 09:00:36AM +, Mike Gabriel wrote: > 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). > I'm not sure I can help you with the latter, since we use sssd and have never 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. :) signature.asc Description: PGP signature
Bug#960676: autofs: update service file
Package: autofs Version: 5.1.7-1 Followup-For: Bug #960676 The current upstream version of autofs provides a sample service file that for Debian would look like this > [Unit] > Description=Automounts filesystems on demand > After=network.target ypbind.service sssd.service network-online.target > remote-fs.target rpc-statd.service rpcbind.service > Wants=network-online.target rpc-statd.service rpcbind.service > > [Service] > Type=notify > EnvironmentFile=-/etc/default/autofs > ExecStart=/usr/sbin/automount $OPTIONS --systemd-service --dont-check-daemon > ExecReload=/usr/bin/kill -HUP $MAINPID > KillMode=process > TimeoutSec=180 > > [Install] > WantedBy=multi-user.targe 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. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/6 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages autofs depends on: ii init-system-helpers 1.60 ii libc62.31-12 ii libnsl2 1.3.0-2 ii libtirpc31.3.1-1 ii libxml2 2.9.10+dfsg-6.7 ii ucf 3.0043 Versions of packages autofs recommends: ii e2fsprogs 1.46.2-1 ii kmod28-1 ii nfs-common 1:1.3.4-5 autofs suggests no packages. -- no debconf information
Bug#960676: autofs: update service file
Package: autofs Version: 5.1.2-4 Severity: wishlist 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 --pid-file /var/run/autofs.pid which should be changed for consistency. 2) Type=forking could be changed to Type=simple, when the -f option is added. In this mode autofs logs to stderr instead of syslog, so it might be advisable to also set SyslogIdentifier= -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages autofs depends on: ii libc62.28-10 ii libxml2 2.9.4+dfsg1-7+b3 ii ucf 3.0038+nmu1 Versions of packages autofs recommends: ii e2fsprogs 1.44.5-1+deb10u3 ii kmod26-1 ii nfs-common 1:1.3.4-2.5 autofs suggests no packages. -- no debconf information
