Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: michibaby on 2014/06/05, 20:07:20
-
Hallo zusammen,
ich habe mein bestehendes System auf systemd aktualisiert. Bisher habe ich NFS shares beim Systemstart automatisch eingehängt. Nach der Systemaktualisierung bleibt das System, nach dem Prüfen der Partitionen, hängen. Wenn ich in der fstab die NFS-shares auskommentiere, fährt das System hoch. Nach systemctl status nfs-common wird der ordnungsgemäße Start von nfs-common angezeigt. Ein mounten der Shares ist nun möglich. Was muß ich ändern, um beim Systemstart die Shares einzuhängen?
Der Thread "http://forum.siduction.org/index.php?topic=4530.msg37515#msg37515 (http://forum.siduction.org/index.php?topic=4530.msg37515#msg37515)" hat nicht geholfen.
Michibaby
-
Zeig mal bitte die entsprechenden Einträge in der fstab.
greetz
devil
-
Hi michibaby,
die nfs-Shares müssen so ausschauen in der fstab:
Beispiel:
diskstation:/volume1/VM /mnt/import/vm nfs rw,noauto,users,x-systemd.automount,vers=3 0 0
Entscheidend ist dabei das x-systemd.automount.
-
Mal ne Frage dazu: Was passiert dann in diesem Fall wenn diese Shares beim booten oder später zeitweilig nicht verfügbar sind ?
Wir der Auruf erstmal ignoriert und die Shares dann eingehängt wenn sie verfügbar werden ?
Ich habe nfs-Shares auf nem Rechner (MutiMedia Rechner/Server) der nicht immer läuft und habe dies bei mir mit autofs bisher ganz zufriedenstellend gelöst. Mußß halt jedesmal wenn ich die Shares brauch sicherstellen dass der Rechner hochgefahren ist und dann den Share benutzen.
Wenn das "automatisch" ginge wäre mir das halt lieber.
Grüße
Reiner
-
Hi ReinerS,
du musst halt mit der Option noauto die NFS-shares in der fstab eintragen, dann wird erstmal nichts gemountet bei Booten. Bei Bedarf kannst du das händisch oder per Automount einhängen lassen.
Ich hab' hier ein NAS mit NFS-Shares, das zum Bootzeitpunkt des PC's auch nicht immer an ist. Mit meiner weiter oben geposteten fstab-Zeile geht das problemlos. Wenn ich dann NFS-Share nutze wird er automatisch gemountet.
-
Hallo,
es ist eine durchaus störende Eigenschaft, wenn nachrangige Vorgänge den kompletten Bootvorgang scheitern lassen.
Die Option "nofail" erlaubt, dass das Booten nicht fehlschlägt, wenn ein Dateisystem nicht gemountet werden kann. Dies könnte die Erlösung sein, aber leider ist unklar, in welcher Version von systemd.mount diese Option implementiert wurde und ob sie in Debians Version 204 schon enthalten ist.
Auch die Kombination mit "x-systemd.device-timeout=10" zur Vermeidung ewig langer Timeouts scheint mir hier sinnvoll.
Grüße
musca
-
Hallo bluelupo,
ich habe den Eintrag in der fstab schon geändert:
"192.168.178.100:/mnt/Doc_Michael /home/michael/Documents/ nfs defaults,x-systemd.automount,x-systemd.device-timeout=10,defaults 0 0"
Leider hilft dies auch nicht! Aufgrund der Datenstruktur (home-Verzeichnis auf dem Server) benötige ich das Einbinden der NFS-Shares zum Zeitpunkt des Boot-Vorganges.
Kann dieses Verhalten daran liegen, daß die Netzwerkkarte zum Zeitpunkt des Einbindeversuchs noch nicht konfiguriert ist??? Wie gesagt, mit dem SysVInit funktioniert alles bestens. Da beim systemd alles parallel laufen sollte, kann es da passieren, daß die Netzwerkschnittstelle noch nicht konfiguriert ist??? Wie kann man das systemd dazu zwingen, daß die NFS-Shares erst nach der Netzwerkkonfiguration eingebunden werden?
Michibaby
-
Ich habe eben noch vergessen ein Verhalten darzustellen: wenn ich die Option "noauto" anstelle "default" in der fstab verwende, fährt das System hoch. Aber wie gesagt, da die home-Verzeichnisse aller User auf dem Server liegen, benötige ich ein automatisches Einbinden spätestens zur Anmeldung.
Michibaby
-
Hallo michibaby,
die Option noauto verhindert nur das Blockieren. Das NFS-Share wird trotzdem von systemd.mount automatisch gemountet, deshalb hatte Bluelupo Dir diese Option schon gestern empfohlen.
Grüße
musca
-
Hallo musca,
ich kann mich nur wiederholen (auch nach einem weiteren Test), mit der Option "noauto" werden die Shares nicht automatisch eingehängt(!) - System fährt hoch, aber ohne Shares.
Nach den Studium der man-page zu mount kann ich nur sagen, daß System verhält sich in dieser Beziehung wie beschrieben:
" noauto Can only be mounted explicitly (i.e., the -a option will not cause the filesystem to be mounted)."
Michibaby
-
noauto funktioniert in diesem Zusammenhang natürlich nur zusammen mit x-systemd.automount. Einer muss ja mounten.
greetz
devil
-
Hallo devil,
die Zeile aus meiner fstab
"192.168.178.100:/mnt/Doc_Michael /home/michael/Documents/ nfs noauto,x-systemd.automount,x-systemd.device-timeout=10,defaults 0 0"
Damit kein(!) automatisches mounten!
Nach dem Ersatz von "noauto" durch "default" und einem Auskommentieren; danach hochfahren des Systems; dann ein Entfernen des Kommentarzeichens und anschließendem "mount -a" bindet das Share-Verzeichnis ein. Nur dies geschieht alles nicht beim Hochfahren - das System bleibt einfach stehen.
Michibaby
-
Seltsam, allgmein funktioniert das nämlich. Was ist denn deine systemd-version? Die Änderungen wurden mit 204-9 oder -10 nötig.
greetz
devil
-
Hallo michibaby,
hattest Du bei deinen erfolglosen Versuchen mit "noauto" dann die Option "x-systemd.automount" wieder weggelassen?
Nach meinem Verständnis wird die /etc/fstab nun von systemd.mount ausgewertet und hierbei entsprechende Units generiert.
Zitat aus der man page von systemd.mount:
If x-systemd.automount is set, an automount unit will be created for the file system.
Hierbei verhindert die Option noauto, dass ein Deadlock ensteht, weil Netzwerk und Mount gegenseitig aufeinander warten:
Zunächst wird das NFS-Share ausgelassen, das Netzwerk wird gestartet und danach wird das Share gemountet.
Grüße
musca
[edit] PS. War vor dem Speichern unterbrochen worden, erst nach dem Speichern habe ich gesehen, dass devil dieselben Fakten hinterfragt hat. Sorry für die Wiederholung.
-
Hallo devil, hallo musca,
die Optionen in der fstab:
" ... noauto,x-systemd.automount,x-systemd.device-timeout=10,defaults 0 0"
Die Version von systemd ==> 204-10.
Was ich auch nicht verstehe ist, wieso die Option timeout nichts bewirkt.
Wo würde ich die automount unit finden (zur Kontrolle, ob diese angelegt wurde)? Kann man dieses Anlegen erzwingen?
In /etc/systemd/system stehen bei mir folgende Units:
bluetooth.target.wants
cups.socket.d
dbus-org.bluez.service -> /lib/systemd/system/bluetooth.service
dbus-org.freedesktop.Avahi.service -> /lib/systemd/system/avahi-daemon.service
dbus-org.freedesktop.NetworkManager.service -> /lib/systemd/system/NetworkManager.service
dbus-org.freedesktop.nm-dispatcher.service -> /lib/systemd/system/NetworkManager-dispatcher.service
getty.target.wants
graphical.target.wants
local-fs.target.wants
multi-user.target.wants
network.target.wants
printer.target.wants
sockets.target.wants
sshd.service -> /lib/systemd/system/ssh.service
syslog.service -> /lib/systemd/system/rsyslog.service
Das Verzeichnis /etc/systemd/userist leer.
Michibaby
-
Hallo michibaby,
Man kann den Status inklusive Mountbefehl und Zeitstempel abfragen, wie in dieser (beides gekürzt) Ausgabe zu sehen ist:
# systemctl list-units | grep mount
-.mount loaded active mounted /
data.mount loaded active mounted /data
(...schnipp ...)
# systemctl status data.mount
data.mount - /data
Loaded: loaded (/etc/fstab)
Active: active (mounted) since Mo 2014-06-09 09:51:52 CEST; 10min ago
(... schnapp ...)
# find / -name data.mount -print
/run/systemd/generator/dev-disk-by\x2duuid-44962848\x2d3146\x2d4863\x2da7ee\x2d7643844dd0db.device.wants/data.mount
/run/systemd/generator/data.mount
/run/systemd/generator/local-fs.target.requires/data.mount
Der Name der Unit wird also aus dem Mountpoint abgeleitet und damit kann man die generierte Unit auch im System finden.
Ich weiß aber auch nicht, woran man denn nun eine "automount unit" erkennt.
Grüße
musca
-
Hallo zusammen,
nach einigen Tests habe ich dieses Verhalten festgestellt:
# systemctl list-units | grep mount
zeigt das Ausführen diese units (mount-units der nfs-shares)
home-and...uments.automount loaded active running home-andrea-Documents.automount
home-mic...uments.automount loaded active running home-michael-Documents.automount
Diese units werden anscheinend bei der Auswertung der fstab in /run/systemd/generator/ erstellt.
Ein df zeigt aber das Einbinden der Shares nicht an (mein bisheriges Vorgehen)
root@Rechner-4:~# df
Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda3 20510332 10053628 9391796 52% /
udev 10240 0 10240 0% /dev
tmpfs 1636244 856 1635388 1% /run
tmpfs 4090608 0 4090608 0% /dev/shm
tmpfs 4090608 0 4090608 0% /sys/fs/cgroup
tmpfs 5120 0 5120 0% /run/lock
tmpfs 102400 0 102400 0% /run/user
/dev/sda11 177010240 42588960 125406548 26% /mnt/BackUp
/dev/sda9 206293688 107704532 88087012 56% /mnt/VmWare
/dev/sda10 257899908 126728956 118047368 52% /mnt/Daten_1
/dev/sda8 3030800 1583552 1273580 56% /home
Nachdem ich mich als Nutzer angemeldet habe und in das NFS-Verzeichnis wechselte wird der Inhalt richtig angezeigt:
michael@Rechner-4:~/Documents$ ll
insgesamt 432
-rw-rw-r--+ 1 michael michael 0 Mär 9 2013 ACL-Test-NAS
drwxr-xr-x 2 michael michael 4096 Dez 28 2012 Android
.
.
.
Nach einem weiteren df wird ein NFS-Share zusätzlich angezeigt:
michael@Rechner-4:~/Documents$ df
Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda3 20510332 10053648 9391776 52% /
udev 10240 0 10240 0% /dev
tmpfs 1636244 868 1635376 1% /run
tmpfs 4090608 0 4090608 0% /dev/shm
tmpfs 4090608 0 4090608 0% /sys/fs/cgroup
tmpfs 5120 0 5120 0% /run/lock
tmpfs 102400 0 102400 0% /run/user
/dev/sda11 177010240 42588960 125406548 26% /mnt/BackUp
/dev/sda9 206293688 107704532 88087012 56% /mnt/VmWare
/dev/sda10 257899908 126728956 118047368 52% /mnt/Daten_1
/dev/sda8 3030800 1583552 1273580 56% /home
192.168.178.100:/mnt/Doc_Michael 29239400 15502408 13736592 54% /home/michael/Documents
Nach den Ausführen diese Prozedur mit einem anderen User, wird ein weiteres Share angezeigt:
andrea@Rechner-4:~/Documents$ df
Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf
/dev/sda3 20510332 10053644 9391780 52% /
udev 10240 0 10240 0% /dev
tmpfs 1636244 876 1635368 1% /run
tmpfs 4090608 0 4090608 0% /dev/shm
tmpfs 4090608 0 4090608 0% /sys/fs/cgroup
tmpfs 5120 0 5120 0% /run/lock
tmpfs 102400 0 102400 0% /run/user
/dev/sda11 177010240 42588960 125406548 26% /mnt/BackUp
/dev/sda9 206293688 107704532 88087012 56% /mnt/VmWare
/dev/sda10 257899908 126728956 118047368 52% /mnt/Daten_1
/dev/sda8 3030800 1583552 1273580 56% /home
192.168.178.100:/mnt/Doc_Michael 29239400 15502408 13736592 54% /home/michael/Documents
192.168.178.100:/mnt/Doc_Andrea 29239400 4898832 24340168 17% /home/andrea/Documents
Fazit: die mount units wurden bisher, mit den richtigen Optionen in der fstab, immer ausgeführt. Die Anzeige mit df stellt dies nicht so dar.
Muß anstelle von df ein anderer Befehl genutzt werden, um alle eingehängten Dateisystem angezeigt zu bekommen???
Michibaby
-
Hallo zusammen,
das Verhalten ist geklärt:
"...Für einige dieser Arbeiten bringt Systemd eine Automount-Funktion mit, die Pseudo-Einhängepunkte für in /etc/fstab konfigurierte Dateisysteme anlegen kann; tatsächlich eingebunden werden sie allerdings erst beim ersten Zugriff. Das Hinzufügen von "comment=systemd.automount" in /etc/fstab verwandelt einen beliebigen Mount-Punkt in einen Automount-Punkt. Das kann den Startvorgang beschleunigen und ist beispielsweise für Netzwerkfreigaben nützlich, wenn die Netzverbindung über den NetworkManager erst beim Einloggen eines Users aufgebaut wird. .."
Quelle: http://www.heise.de/open/artikel/Das-Init-System-Systemd-Teil-2-1563461.html?artikelseite=2
Somit scheint ja alles zu funktionieren.
Ich danke allen, die mich unterstützen!
Michibaby