Ubuntu Server 16.04: Probleme mit dem Mounten beim Booten

TiKu

Administrator
Teammitglied
Mitglied seit
16.11.2001
Beiträge
21.664
Renomée
1.247
Standort
München
  • SIMAP Race
  • QMC Race
  • Spinhenge ESL
  • Docking@Home
  • BOINC Pentathlon 2021
Servus,

Ich mounte per fstab einen Samba-Netzwerkshare mehrfach in verschiedene Unterverzeichnisse von /mnt und anschließend diese Pfade mehrfach in verschiedene Unterverzeichnisse von /var. Diese Verzeichnisse unterhalb von /var werden schließlich von einem VSFTP-Server als Homeverzeichnisse von verschiedenen Usern, mit verschiedenen Berechtigungen verwendet.
Das Konstrukt funktioniert sehr gut und ist sehr einfach zu administrieren. Allerdings scheint Linux (oder Samba?) sich beim Booten manchmal etwas zu verschlucken, jedenfalls kommt es ab und an vor, dass die Mountpoints unter /var nach dem Booten keinen Inhalt haben, obwohl auf dem Share Daten liegen. Führt man dann nochmal "mount -a" aus, verschwindet das Problem. Deshalb ist mein Verdacht, dass bereits von /mnt/* nach /var/* gemountet wird, während die Mountpoints unter /mnt/* noch nicht wirklich bereit sind.
In den Logs habe ich noch nicht wirklich etwas hilfreiches gefunden, vielleicht suche ich aber auch an der falschen Stelle.

Kennt jemand das Problem und eine passende Lösung? Gibt es eine Möglichkeit, in der fstab eine Art Pause zu definieren, sodass nach dem Mounten des Shares erstmal 5 Sekunden oder so gewartet wird?

Ich könnte natürlich ein Startup-Skript bauen, das nochmal mount -a ausführt, aber vielleicht gibt es ja etwas eleganteres.

Grüße
TiKu
 
Hi,
da wird wohl das Netz manchmal nicht bereit sein.

Probier zunächst mal folgendes:
Trag in die /etc/rc.local folgendes ein:

Code:
sleep 10
sudo mount -a
exit 0

Dadurch wird mount -a um 10 Sekunden verzögert automatisch nochmal ausgeführt, je nach Bedarf kann sleep natürlich variiert werden. Das ist meines Wissens die einfachste Variante und man mus nicht in der fstab herumbasteln.
Die Bootzeit wird dadurch natürlich um den sleep-Wert erhöht, aber darum kommt man wohl nie wirklich rum.

Ursache dafür, dass es manchmal nicht aufs erste mal klappt könnte übrigens systemd sein, da hier beim Booten die Dienste asynchron gestartet werden.
 
Zuletzt bearbeitet:
In der fstab ist die mount-Reihenfolge richtig angegeben?
Die letzte Zahl ist das.
Passt das nicht bei von einander abhängenden Verzeichnissen funktioniert der mount-Vorgang nicht.
 
Guter Punkt, das muss ich mal prüfen. Ich glaube, da steht überall 0.
 
Das ist auf jeden Fall nicht in Ordnung.

Das root Filesystem sollte 0 haben.
Die nächsten etwa /var dann 1 und ein darauf aufbauendes 2 usw.
Parallelitäten sind erlaubt, aber müssen in die Hierarchie passen.

zB bei einem meiner Rechner sieht es so aus:
Code:
UUID=517ddb21-f591-4bb1-bf50-1cdc2d20b49f /               ext4    rw,errors=remount-ro,noatime,discard 0       1
UUID=7b75cbbf-6720-4b00-b285-543e03794d64 /boot           ext4    rw,noatime,discard        0       2
UUID=e964bb11-a1a2-4a49-b71e-924700ac21fc /data         ext4    rw,noatime,acl,user_xattr,barrier=1     0 [B]2[/B]
UUID=896c1760-2d4a-4733-986f-53769997f1b4 /data/Video   btrfs   defaults,noatime,autodefrag,space_cache 0 [B]3[/B]
 
Ich habe das jetzt mal geändert und werde es beobachten. Beim ersten Bootvorgang nach der Änderung hat schonmal alles gepasst. *great*
 
@tomturbo: Seit wann gibt die letzte Spalte der fstab eine Mountreihenfolge an?
http://man7.org/linux/man-pages/man5/fstab.5.html schrieb:
[NOPARSE]The sixth field (fs_passno).
This field is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time.[/NOPARSE]

Zum eigentlichen Problem: Ich weiß nicht genau, ob Systemd die gleichen Parallelitäten hat wie Upstart. Bei letzterem werden viele Dienste parallel gestartet, was z.B. dazu führen kann, dass Samba startet, wenn LDAP noch gar nicht läuft - was dann ganz toll ist, wenn der Samba auf den LDAP zugreifen soll und dessen Nutzer-DB benutzt. Worauf ich hinaus will: Bei Upstart kann man zusätzliche Abhängigkeiten der Dienste voneinander definieren (in /etc/init/<dienstname>.conf), vielleicht geht das auch bei Systemd. Wenn das geht, würde ich vsftpd erst starten, wenn Netzwerk und Samba läuft und die Mounts durch sind.

Grüße
Dalai
 
Bei mir war es bisher immer so, dass dies auch die Mountreihenfolge war.
Muss wohl mal in den Sourcecode gucken.
 
Hm, jetzt hast du mich echt verunsichert Dalai.
Somit ziehe ich meine Empfehlung an TiKu zurück.
Die cifs mounts sollten jedenfalls 0 haben.

Ubuntu verwendet "mountall" zum Mounten, nicht etwa "mount -a", was sequentiell die fstab abarbeitet.
Anscheinend wird oft empfohlen im rc.local zu mounten...
Was bei Systemd so ne Sache ist.
 
Zuletzt bearbeitet:
Was bei Systemd so ne Sache ist.
Ich hatte da auch ein bisschen Probleme mit der Bootreihenfolge, da vor dem Mounten noch cryptsetup ausgeführt werden muss und das hat nicht immer optimal funktioniert.

Prinzipiell sollte systemd aber die Reihenfolge automatisch anpassen, d.h. z.B. /var nicht vor / gemountet werden.
Die fstab hat da meines Wissens nichts zu sagen, daraus werden nur automatisch die Units erstellt.

Für mich persönlich hatte ich es so gelöst, dass ich /home nicht in die fstab eingetragen hab, sondern stattdessen Units für Decrypt und Mount geschrieben hab.
Das geht ja zum Glück sehr schnell und so funktioniert es auch wunderbar.
Bei dem Ansatz ist es dann aber wichtig, dass es nicht in fstab steht, denn sonst kommt es zu Kollisionen mit den automatisch erzeugten Units.
Evtl. kann man systemd auch irgendwie mitteilen einen Eintrag in fstab zu ignorieren.

Generell war ich nicht ganz happy damit, wie systemd das hier löst und insbesondere mit der Anpassung, wenn man vom Standard abweicht.
 
Tatsächlich ist das Problem heute wieder aufgetreten, d.h. ich kann bestätigen, dass die letzte Zahl in den fstab-Einträgen das Problem nicht lösen kann.

Ich schaue mir die Tage dann mal den von tomturbo verlinkten Artikel genau an und setze das um.
 
Ich habe die fstab nun um die systemd-Optionen erweitert und es scheint prinzipiell zu funktionieren. Allerdings sehe ich im Log diesen Block:
Code:
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Found ordering cycle on local-fs.target/start
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Found dependency on var-ftp-hotline.automount/start
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Found dependency on mnt-ftp.automount/start
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Found dependency on network-online.target/start
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Found dependency on network.target/start
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Found dependency on networking.service/start
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Found dependency on local-fs.target/start
Mar 26 16:53:59 compeso-ftp systemd[1]: local-fs.target: Breaking ordering cycle by deleting job var-ftp-hotline.automount/start
Mar 26 16:53:59 compeso-ftp systemd[1]: var-ftp-hotline.automount: Job var-ftp-hotline.automount/start deleted to break ordering cycle starting with local-fs.target/start
Das sieht so aus, als würde das Netzwerk von local-fs abhängen, was wiederum von meinen Mountpoints abhängt. Dadurch entsteht eine Zirkelreferenz, weshalb eine der Abhängigkeiten ignoriert wird, wodurch das ganze eigentlich unzuverlässig ist. Eigentlich dürfte local-fs nicht von meinen Mountpoints abhängen. Ich verstehe diese Abhängigkeit nicht ganz.
Meine fstab sieht in etwa so aus:
Code:
//192.168.143.xx/ftp            /mnt/ftp              cifs   guest,auto,noperm,iocharset=utf8,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10       0       0
/mnt/ftp                        /var/ftp/hotline      none   bind,x-systemd.automount,x-systemd.requires=mnt-ftp.automount      0       0

Wie bekomme ich die Zirkelreferenz weg?

/EDIT: Okay, wenn man bei /var/ftp/hotline die Option _netdev angibt, ist die Zirkelreferenz weg. Dafür wird nun erst /var/ftp/hotline gemountet und danach /mnt/ftp, wodurch der FTP-Server keine Dateien anzeigt. Argh!

/EDIT2: x-systemd.requires=mnt-ftp.mount statt x-systemd.requires=mnt-ftp.automount scheint zu helfen. Ob nun wirklich alles passt, weiß ich dann nach einigen Dutzend Reboots.
 
Zuletzt bearbeitet:
Könntest
Code:
x-systemd.before=ftp.service
testen.
(oder wie auch immer die service unit für den FTP server heißt)
 
Zurück
Oben Unten