staging.inyokaproject.org

Der in 40189 beschriebene Bug ist in Autofs 5.1.2-1ubuntu2 gefixt. Dies konnte ich heute bei einem Test in Bionic Beaver testen. Ich hoffe, dass es auch für Xenial noch ein Update geben wird, dass diesen Bug fixt. Immerhin ist diese Version noch drei Jahre unter Support.

MfG
Tronde

Guten Abend.

Nach ein paar weiteren Tests bin ich nun vollständig verwirrt. Ich habe ein neues Ubuntu GNOME 16.04 mit autofs installiert:

1
2
3

uname -r
4.4.0-116-generic
autofs/xenial-updates 5.1.1-1ubuntu3.1 amd64

In dem neu installierten System kann ich direkt nach dem Start via automount auf die Freigaben zugreifen. Auf meinem Notebook jedoch erst nach einem sudo systemctl restart autofs. Und das bei gleichem Kernel und gleicher autofs-Version. Nicht zu wissen was hier anders ist, treibt mich noch in den Wahnsinn. 👿 😕

Ich würde so gern die Ursache herausfinden was auf meinem Notebook anders ist und klemmt, um es dann gezielt beheben zu können. 😇

Falls hier noch jemand mitliest und mir helfen kann, freue ich mich auf Tipps und Hinweise jeder Art.

Deprimiert
Tronde

Guten Abend,

ich möchte gern meine neuesten Erkenntnisse hier mit euch teilen, in der Hoffnung, dass doch noch jemand eine Idee hat.

Nach dem Start meines Notebooks habe ich geprüft, ob der Dienst autofs.service läuft:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

● autofs.service - LSB: Automounts filesystems on demand
   Loaded: loaded (/etc/init.d/autofs; bad; vendor preset: enabled)
   Active: active (running) since Do 2018-03-22 22:23:25 CET; 3min 42s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1158 ExecStart=/etc/init.d/autofs start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/autofs.service
           └─1226 /usr/sbin/automount --pid-file /var/run/autofs.pid

Mär 22 22:23:24 T410 systemd[1]: Starting LSB: Automounts filesystems on demand...
Mär 22 22:23:25 T410 autofs[1158]:  * Starting automount...
Mär 22 22:23:25 T410 autofs[1158]:    ...done.
Mär 22 22:23:25 T410 systemd[1]: Started LSB: Automounts filesystems on demand.

Anschließend habe ich mir mit tcpdump und strace angesehen, was passiert wenn ich ls -ld $MOUNTPOINT ausführe. Ich war etwas überrascht, dass nicht ein einziges Paket meine Netzwerkschnittstelle Richtung NAS verlässt, obwohl ich das NAS zuvor erfolgreich angepingt habe. Der entsprechende Syscall in strace sieht dabei wie folgt aus:

1

lstat("$MOUNTPOINT", 0x1bc11a0)   = -1 ENOENT (No such file or directory)

Nach einem sudo systemctl restart autofs.service funktioniert dann alles wie gewünscht. Es gehen Pakete über das Netzwerk und strace zeigt:

1

lstat("$MOUNTPOINT", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0

Das Problem ist auf mein Notebook beschränkt. Wie schon beschrieben funktioniert es in einer frisch installierten VM nach dem Bootvorgang sofort.

❓ Woran kann es liegen, dass dies auf meinem Notebook erst nach einem Restart des Dienstes funtioniert? ❓

MfG
Tronde

Der alte Automounter ist ja (leider) noch ein Initscript. Eventuell wird das zu früh ausgeführt während de Bootvorgangs und daher haben wir den Salat.

mfg Stefan

Hi,

das könnte natürlich sein. Hast du eine Idee, wie ich dies überprüfen kann, außer den Startwert in den Runleveln versuchsweise zu verändern? Ist es denn ein SysVinit- oder ein Upstart-Skript? Wenn ich mich nicht irre, sind beide vorhanden, es wird jedoch das SysVinit-Skript durch systemd ausgeführt.

Ich habe noch mit einem weiteren Gerät getestet. Insgesamt habe ich die Tests auf einem Thinkpad T410, einem X201 und in einer VM unter VirtualBox ausgeführt. Alle drei Systeme nutzen autofs 5.1.1-1ubuntu3.1 und Kernel 4.4.0-116-generic. Während die VM wie erwartet funktioniert, muss autofs auf den ThinkPads erst neugestartet werden, bevor es sich nutzen lässt.

Edit: Dieser Bug tritt wie weiter oben beschrieben mit autofs 5.1.2-1ubuntu2 nicht mehr auf. Ich würde mich freuen, wenn es einen Software-Update für Xenial gibt, da dessen Support noch bis 2021 läuft. Jedoch glaube ich da langsam nicht mehr dran. Ich tröste mich damit, dass das Release von Bionic nicht mehr weit entfernt ist. Ich werde das Release-Upgrade dann evtl. einfach früher als geplant durchführen.

MfG
Tronde

Probier doch vielleicht, die neue Version testweise auf xenial zu installieren?

Guten Morgen,

ich bin deinem Vorschlag gefolgt und habe das Paket aus Bionic testweise unter Xenial installiert. Mit Bedauern musste ich feststellen, dass sich das Verhalten dadurch nicht geändert hat. ☹

Damit schwindet meine Hoffnung, dass das Problem durch ein Software-Update behoben werden kann. Darüber hinaus keimt in mir der Verdacht, die ganze Zeit an der falschen Stelle zu suchen. 😕

Die mit Version 5.1.2 installierte Service-Unit scheint nicht mehr das alte Initscript aufzurufen, sondern verwendet direkt das Binary aus /usr/sbin/automount.

Ich bin verwirrt und weiß aktuell nicht, wie am geschicktesten weiter vorzugehen ist.

MfG
Tronde

Es klingt so, als ob autofs startet, bevor die Netzwerkverbindung aufgebaut ist - wenn du den Network-Manager nutzt, könntest du mal nachsehen, ob NetworkManager-wait-online.service aktiviert wurde, damit das network-online.target erst dann erreicht wird, wenn die Verbindung steht - vgl. https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.

Und alle von einer funktionierenden Netzwerkverbindung abhängigen Dienste dürfen erst nach Erreichen des network-online.target starten. Gegebenenfalls muss man also noch eine Regel wie

After=network-online.target

in einer Drop-In Datei für die Unit (vgl. https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description) ergänzen.

Guten Morgen,

NetworkManager-wait-online.service wurde bei mir aktiviert. In der Service-Unit der Version 5.1.2 steht folgendes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

[Unit]
Description=Automounts filesystems on demand
After=network.target ypbind.service sssd.service network-online.target remote-fs.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/var/run/autofs.pid
EnvironmentFile=-/etc/default/autofs
ExecStart=/usr/sbin/automount $OPTIONS --pid-file /var/run/autofs.pid
ExecReload=/bin/kill -HUP $MAINPID
TimeoutSec=180

[Install]
WantedBy=multi-user.target

Damit sollte eigentlich sichergestellt sein, dass der autofs.service erst startet, wenn das Netzwerk online ist.