Automount funktioniert nicht, IDE IF SATA

[Torsten73]

Fortsetzung vom alten Thread, da ich keine Imageplatzer mehr habe, aber trotzdem nach 2 erfolgreichen Aufnahmen am nächsten Tag wieder keinen Mounts habe, jetzt hier unter neuem Thema.

Gar nicht mounten ist allerdings auch nicht korrekt:

Code: Alles auswählen

~ > df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                 6080      6080         0 100% /
/dev/mtdblock/3           1408       724       684  51% /var
tmpfs                   131072         4    131068   0% /tmp
/dev/ide/host0/bus0/target0/lun0/part2
                     311241232  40698648 270542584  13% /hdd
~ > umount

Die Auto.net ist unverändert:

Code: Alles auswählen

Hdd_Sylvia -fstype=nfs,rw,nolock,rsize=32768,wsize=32768 192.168.0.100:/hdd
Serien -fstype=nfs,ro,nolock,rsize=32768 192.168.0.10:/Serien
Fotos -fstype=nfs,ro,nolock,rsize=32768 192.168.0.10:/Fotos
Musik -fstype=nfs,ro,nolock,rsize=32768 192.168.0.10:/Musik
Unsere_Videoaufnahmen -fstype=nfs,ro,nolock,rsize=32768 192.168.0.10:/Unsere_Videoaufnahmen
Neue_Aufnahmen -fstype=nfs,rw,nolock,rsize=16348,wsize=16348 192.168.0.10:/Neue_Aufnahmen
Fitness -fstype=nfs,rw,nolock,rsize=32768,wsize=32768 192.168.0.10:/Fitness
Filmarchiv -fstype=nfs,ro,nolock,rsize=16348 192.168.0.10:/Filmarchiv

Woran könnte es noch liegen? Bootlog erforderlich?

Thx
Torsten

[Torsten73]

Code: Alles auswählen

~ > fsck.ext2 -fvy /dev/ide/host0/bus0/target0/lun0/part2
e2fsck 1.41.9 (22-Aug-2009)
Superblock last mount time (Sun Nov  2 09:15:12 1958,
        now = Thu Oct 22 00:03:37 2009) is in the future.
Fix? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/ide/host0/bus0/target0/lun0/part2: ***** FILE SYSTEM WAS MODIFIED *****

      38 inodes used (0.01%)
       0 non-contiguous files (0.0%)
       1 non-contiguous directory (2.6%)
         # of inodes with ind/dind/tind blocks: 14/14/0
10189238 blocks used (13.09%)
       0 bad blocks
      15 large files

      27 regular files
       2 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
       0 symbolic links (0 fast symbolic links)
       0 sockets
--------
      29 files
~ >

[seife]

Die Ausgabe von df sieht 100% i.O. aus, der Automounter mounted nur dann, wenn auf den Pfad zugegriffen wird, insofern kann ich da keinen Fehler sehen.

in /proc/mounts kannst du sehen, ob der automount prinzipiell gemounted ist:

Code: Alles auswählen

rootfs / rootfs rw 0 0
/dev/root / squashfs ro 0 0
none /dev devfs rw 0 0
proc /proc proc rw 0 0
tmpfs /tmp tmpfs rw 0 0
/dev/mtdblock/3 /var jffs2 rw 0 0
automount(pid131) /tmp/automount autofs rw 0 0

df:

Code: Alles auswählen

/var # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                 5376      5376         0 100% /
tmpfs                    15444        16     15428   0% /tmp
/dev/mtdblock/3           2176      1104      1072  51% /var

Wenn es bei dir nicht funktioniert, wirst du autofs debuggen müssen. Davon habe ich keine Ahnung, weil ich bisher noch nie eine Fehlfunktion hatte

[Torsten73]

Hallo seife,
Danke für Deine Antwort.
Ich sehe bisher auch keine wirkliche Ursache. in proc/mount ist ein symlink vorhanden. Ich vermute das meinst Du.
Es ist ja auch so dass gemountet wird, aber nicht ins AufoFS Verzeichniss und nur die interne Hdd nach /hdd.

Debuggen kann ich leider ebsowenig.

Cu
Torsten

[seife]

in /proc/mounts steht drin (Inhalt), ob der Automounter läuft / ob das autofs-"Pseudofilesystem" gemounted ist, wie ich oben rauskopiert habe.

/proc/mount habe ich gar nicht (weder auf Kernel 2.4 noch auf 2.6).

Mit einem Bootlog wirst du nicht weit kommen weil
a) das Problem lange nach dem booten auftreten wird
b) der automounter per default und ohne syslog sehr "stumm" ist.

[rhabarber1848]

Heute morgen hatte ich erstmals das Problem, dass
einer meiner zwei automounts nicht erreichbar war.
Beide mounts zeigen auf NFS-Server, die auf jeweils
anderen Maschinen laufen.

Über das Wochenende lief NFS-Server A 24h lang
durch, es wurden problemlos Aufnahmen durchgeführt.
Gestern abend habe ich diesen Rechner heruntergefahren,
die Dbox lief weiterhin. Heute morgen habe ich den
Rechner mit NFS-Server A gestartet, per automount
hatte ich allerdings keinen Zugriff auf meine Aufnahmen.

Code: Alles auswählen

/var/autofs # ls -la
ls: ./router: Permission denied
drwxr-xr-x    4 root     root            0 Sep 26 16:57 .
drwxr-xr-x   16 root     root            0 Jan  1  1970 ..
drwxrwxrwx    2 root     root           48 Oct  7 11:30 server2

Code: Alles auswählen

/var/autofs # cd router
-sh: cd: can't cd to router

Code: Alles auswählen

/var/autofs # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.6M      5.6M         0 100% /
/dev/mtdblock/3           2.1M      1.2M    956.0K  56% /var
192.168.1.8:/disk/dbox2
                         16.0E         0     16.0E   0% /var/autofs/router
192.168.1.1:/mnt/dbox_record
                         13.4G     10.2G      3.2G  76% /var/autofs/server2

Zum Zeitpunkt dieser Befehle war NFS-Server B gestartet
und konnte von automount problemlos genutzt werden,
ohne das automount neugestartet werden musste.
Gleichzeitig zum "df -h"-Befehl tauchte im Bootlog das auf:

Code: Alles auswählen

nfs_statfs: statfs error = 13

was wohl die 16.0E Gesamtspeicher auf NFS-Server A
erklären soll...
Leider habe ich nicht den Befehl "mount" ausgeführt,
bevor ich "umount /var/autofs/router" ausgeführt habe.

Danach konnte ich wieder auf NFS-Server A per
automount zugreifen:

Code: Alles auswählen

/var/autofs # ls -la
drwxr-xr-x    4 root     root            0 Sep 26 16:57 .
drwxr-xr-x   16 root     root            0 Jan  1  1970 ..
drwxrwxrwx    2 root     root           48 Oct  7 11:30 server2
dr-xr-xr-x    2 root     root            0 Sep 26 16:57 router

Code: Alles auswählen

/var/autofs # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.6M      5.6M         0 100% /
/dev/mtdblock/3           2.1M      1.2M    952.0K  56% /var
192.168.1.8:/disk/dbox2
                         32.3G     29.2G      1.4G  95% /var/autofs/router
192.168.1.1:/mnt/dbox_record
                         13.4G     10.2G      3.2G  76% /var/autofs/server2

[rhabarber1848]

Da der NFS-Server A-automount ansonsten das
Ausschalten des NFS-Servers A über Nacht überlebt,
habe ich nachgedacht, was gestern anders war.

Ich vermute, dass zum Zeitpunkt des Herunterfahrens
des NFS-Servers A der mount noch aktiv war, da
ich kurz zuvor eine Aufnahme angesehen habe.
Da ich das relativ selten mache, vermute ich, dass
der automount-daemon diesen NFS-mount in den
vergangenen Monaten bereits wieder ausgehängt
bzw. nie gemountet hat und es deshalb keine
Probleme gab.

Ich fahre den Rechner, auf dem NFS-Server A läuft,
über die Dbox herunter, deshalb werde ich in das
besagte Skript einen umount-Befehl einbauen,
um automount nicht zu verwirren.

[seife]

Du könntest auch mit dem automount-timeout experimentieren. Einfach statt 600 Sekunden mal die 30 Sekunden, die für's debugging vorgesehen sind, eintragen, oder noch weniger. Ausser vermehrten Logeinträgen auf dem Server sollte das keine besonderen Nebenwirkungen haben, da ja so ein NFS-mount flott vonstatten geht.

Anstelle einem expliziten umount sollte sonst auch ein USR1-Signal and den automount ausreichen, um ihn alle mounts unmounten zu lassen.

[rhabarber1848]

Einfach statt 600 Sekunden mal die 30 Sekunden

Damit wird das Problem allerdings nicht 100% gelöst, es tritt nur seltener auf.

Anstelle einem expliziten umount sollte sonst auch ein USR1-Signal and den automount ausreichen, um ihn alle mounts unmounten zu lassen.

Damit schon eher, das habe ich gerade eingebaut, danke!
Habe zudem gerade festgestellt, dass diese Info auch in
start_automount zu finden ist

[seife]

Habe ich richtig verstanden, dass das problem ist, dass automount versucht, das Verzeichnis zu unmounten, der server aber nicht mehr da ist. Daraufhin schlägt der umount fehl und das Verzeichnis bleibt gemounted. Wenn der Server wieder da ist, wird versucht, darauf zuzugreifen, was wiederum fehlschlägt, weil das Verzeichnis dann "ungültig ist". Wenn du dann unmountest, dann kann automount wieder mounten und alles ist gut?

Wenn dem so wäre, dann könnte man ja im automount, wann immer er mit einem Fehler zurückkommen würde erst nochmal versuchen zu unmounten und neu zu mounten, und erst wenn das immer noch Fehlschlägt, mit einem Fehler aussteigen...

Allerdings ist die Frage, ob der Fehler überhaupt vom automount kommt, denn wenn das Verzeichnis schon gemounted ist (sein sollte), dann kann es sein, dass der Request gar nicht bis zum automounter kommt und schon der Kernel "geh weg!" sagt.

...ausserdem sollte, AFAIR, ein NFS-mount das rebooten des Servers überleben, da NFS stateless ist. Kann allerdings sein, dass das nur für UDP gilt, ist schon ne Weile her, dass ich das "gelernt" habe, damals war NFS über TCP noch "very experimental"

[rhabarber1848]

Wenn du dann unmountest, dann kann automount wieder mounten und alles ist gut?

Ja.

dass der Request gar nicht bis zum automounter kommt und schon der Kernel "geh weg!" sagt.

Das vermute ich auch, besonders im Hinblick die "nfs_statfs"-
Fehlermeldung und das nicht erreichbare Verzeichnis /var/autofs/router.

Kann allerdings sein, dass das nur für UDP gilt

Ich nutze NFS via UDP:

Code: Alles auswählen

192.168.1.8:/disk/dbox2 on /var/autofs/router type nfs (rw,v3,rsize=8192,wsize=8192,hard,udp,nolock,addr=192.168.1.8)