[GELÖST] systemd.automount werden beim Booten gemountet

[scientific]

Hi Leute.

Ich hänge immer noch bei systemd und dem Automount. Wie kann ich rausfinden, warum ein target gestartet wird?

Das Problem ist, ich habe zwei Mountpunkte, die sollen bei eingesteckter externer HD ein automount bekommen. Wenn die Platte ausgesteckt ist, sollen denen die automounts entzogen werden.

Gelöst hab ich das derzeit so:

Zwei UDEV-Regeln:

Code: Alles auswählen

ACTION=="add|change", KERNEL=="sd?6", SUBSYSTEMS=="usb", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="YYYY", SYMLINK+="disk/mars" \
 TAG+="systemd", ENV{SYSTEMD_WANTS}+="backup-automount.target"

ACTION=="remove", KERNEL=="sd?6", SUBSYSTEMS=="usb", ENV{ID_FS_UUID}=="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", \
 ENV{ID_MODEL}="$VENDOR_$SERIALNUMMER", \
 RUN+="/bin/systemctl --no-block stop backup-automount.target"

Dazu hab ich /etc/systemd/system/backup-automount.target mit dem Inhalt angelegt

Code: Alles auswählen

[Unit]
Description=Activate automount on backup-mountpoints
Conficts=shutdown.target
Before=shutdown.target
Documentation=man:systemd.special(7)

Und die beiden automount.units:

/etc/systemd/system/backup.automount

Code: Alles auswählen

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
Conflicts=umount.target
Before=umount.target
BindsTo=backup-automount.target
[Automount]
Where=/backup

[Install]
WantedBy=backup-automount.target

und /etc/systemd/system/var-cache-backup.automount

Code: Alles auswählen

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
Conflicts=umount.target
Before=umount.target
BindsTo=backup-automount.target
[Automount]
Where=/var/cache/backup

[Install]
WantedBy=backup-automount.target

Beim Booten wird jetzt - so die Platte eingesteckt ist - backup-automount.target gestartet. Ich nehme an, das ist wegen der udev-Regel. Denn wenn die Platte nicht eingesteckt ist, und später eingesteckt wird, springt ebenfalls udev korrekt an und dieses Target wird gestartet. Die beiden Automounts werden angelegt und auch beim Entfernen wieder gelöscht. So soll es sein.

Aber warum wird dann auch gleich beim Booten gemountet? Entferne ich nämlich dieses backup-automount.target, werden die beiden Mountpunkte beim Booten NICHT gemountet.

Wie kann ich rausfinden, warum jetzt die Platte gemountet wird, wenn automount gestartet wurde (gilt nur beim Booten!!!)?

[scientific]

Keine Ideen?

lg scientific

[smutbert]

Deinen letzten Thread zu dem Thema habe ich so einigermaßen mitverfolgt, aber mir ist jetzt ua nicht ganz klar, wieso das ENV{SYSTEMD_WANTS}+="backup-automount.target" in der add/change-udev-Regel (notwendig) ist. Und wie sieht der zugehörige fstab-Eintrag aus?

[scientific]

Die Absicht dahinter ist:
Ich stecke die externe HD ein. UDEV erkennt sie und aktiviert die automounts an zwei Verzeichnissen:
/var/log/backup
/backup

Erst wenn ich auf diese Mountpunkte zugreife, sollen diese gemountet werden. Das heißt, es wird die Kette "Festplatte entsperren" -> "Mounten von /var/cache/backup" -> "Mounten von /backup" ausgelöst werden. (Oder eben ohne /backup)

Wird die Festplatte ausgesteckt, sollen die Automounts von diesen beiden Mountpunkten entfernt werden, damit ein ls auf diese Mountpoints das ausgibt, was tatsächlich in diesen Verzeichnissen liegt (sollten eigentlich leer sein...) bzw. das ls soll nicht ins Leere laufen, da ja keine HD angesteckt ist, die entsperrt und gemountet werden kann...

Ein manuelles

Code: Alles auswählen

systemctl start backup.automount var-cache-backup.automount

setzt nur die automounts, mountet aber nicht automatisch.
Das "backup-automount.target" hat als "Wants" nur die beiden automounts angegeben. Sonst nichts...

[smutbert]

Das wars…

Wird die Festplatte ausgesteckt, sollen die Automounts von diesen beiden Mountpunkten entfernt werden, damit ein ls auf diese Mountpoints das ausgibt, was tatsächlich in diesen Verzeichnissen liegt (sollten eigentlich leer sein...) bzw. das ls soll nicht ins Leere laufen, da ja keine HD angesteckt ist, die entsperrt und gemountet werden kann...

…was ich nicht bedacht habe (ich wollte darauf hinaus, dass der automounter ja ohnehin immer laufen soll/darf) und im anderen Thread habe ich gerade gelesen, dass du noauto als Mountoption drin hast, was dann wohl heißt, dass ich keine Idee habe.

[scientific]

Das wars…

Wird die Festplatte ausgesteckt, sollen die Automounts von diesen beiden Mountpunkten entfernt werden, damit ein ls auf diese Mountpoints das ausgibt, was tatsächlich in diesen Verzeichnissen liegt (sollten eigentlich leer sein...) bzw. das ls soll nicht ins Leere laufen, da ja keine HD angesteckt ist, die entsperrt und gemountet werden kann...

…was ich nicht bedacht habe (ich wollte darauf hinaus, dass der automounter ja ohnehin immer laufen soll/darf) und im anderen Thread habe ich gerade gelesen, dass du noauto als Mountoption drin hast, was dann wohl heißt, dass ich keine Idee habe.

Immerhin zu wissen, keine Idee zu haben, ist auch schon sehr viel wert...

Im übrigen hab ich die Zeilen in der fstab auskommentiert und arbeite nur mehr mit den systemd-units für diese Mountgeschichte...

[habakug]

Hallo!

Man kann mit

Code: Alles auswählen

# systemd-cgls -a

eine Übersicht der gestarteten Komponenten einsehen.
Besser ist es jedoch die ganze Arbeit des systemd mitzuloggen. Hierzu müssen dem Kernel folgende Parameter mitgegeben werden:

Code: Alles auswählen

systemd.log_level=debug systemd.log_target=kmsg

Jetzt läuft der systemd-Debug in dmesg hinein. Nach dem Start hat man eine ausführliche Logdatei:

Code: Alles auswählen

# dmesg >> dmesg_systemd_log.txt

[OT]
...in der sich z.B. auch solche Perlen finden:

systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/sy ... -is-broken for more information.

[/OT]

Gruss, habakug

[scientific]

Hallo!

Man kann mit

Code: Alles auswählen

# systemd-cgls -a

eine Übersicht der gestarteten Komponenten einsehen.
Besser ist es jedoch die ganze Arbeit des systemd mitzuloggen. Hierzu müssen dem Kernel folgende Parameter mitgegeben werden:

Code: Alles auswählen

systemd.log_level=debug systemd.log_target=kmsg

Jetzt läuft der systemd-Debug in dmesg hinein. Nach dem Start hat man eine ausführliche Logdatei:

Code: Alles auswählen

# dmesg >> dmesg_systemd_log.txt

[OT]
...in der sich z.B. auch solche Perlen finden:

systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/sy ... -is-broken for more information.

[/OT]

Gruss, habakug

Hmmm... dmesg ist ein Ringpuffer? Denn das Log beginnt genau dort wo offenbar schon der entscheidende Dienst gestartet wurde, der einen Mount verursacht.

Das ist der Beginn des Logs nach deiner Anleitung:

Code: Alles auswählen

[   35.147991] systemd[1]: Got SIGCHLD for process 1778 (mount)
[   35.148080] systemd[1]: Child 1778 died (code=exited, status=0/SUCCESS)
[   35.148084] systemd[1]: Child 1778 belongs to var-cache-backup.mount
[   35.148099] systemd[1]: var-cache-backup.mount mount process exited, code=exited status=0
[   35.148109] systemd[1]: var-cache-backup.mount changed mounting-done -> mounted
[   35.148228] systemd[1783]: Executing: /bin/mount /var/cache/backup/var-spool-cyrus.rdiff /var/cache/backup/snapshots/mailbackup -t fuse.rdiff-backup-fs -o revisions=3,ro,noauto,nofail

Aber immerhin hab ich jetzt einen wertvollen Hinweis... nur warum mailbackup gestartet wird... ist mir unerklärlich... weil:

Code: Alles auswählen

root@debian:/etc/systemd/system # cat var-cache-backup-snapshots-mailbackup.mount 
# Automatically generated by systemd-fstab-generator

[Unit]
Description=Mounting of Email-Backup /var/cache/backup/snapshots/mailbackup
DefaultDependencies=no
#Wants=var-cache-backup.mount
PartOf=var-cache-backup.mount

[Mount]
What=/var/cache/backup/var-spool-cyrus.rdiff
Where=/var/cache/backup/snapshots/mailbackup
Type=fuse.rdiff-backup-fs
FsckPassNo=0
Options=revisions=3,ro,noauto,nofail

Und

Code: Alles auswählen

root@pluto[10:35]:/etc/systemd/system # cat var-cache-backup.mount 
# Automatically generated by systemd-fstab-generator

[Unit]
Description=Mounting of Backup-Volume /var/cache/backup
Wants=systemd-cryptsetup@mars.service
After=systemd-cryptsetup@mars.service
Wants=var-cache-backup-snapshots-mailbackup.mount
BindsTo=var-cache-backup-snapshots-mailbackup.mount
Before=var-cache-backup-snapshots-mailbackup.mount
Conflicts=suspend.target
Before=suspend.target
DefaultDependencies=no

[Mount]
What=/dev/mapper/mars
Where=/var/cache/backup
Type=ext4
FsckPassNo=0
Options=defaults,noauto

Und um mal ein nettes Feature von systemd zu nützen... hier die Abhängigkeiten graphisch dargestellt:

Code: Alles auswählen

  Color legend: black     = Requires
                 dark blue = Requisite
                 dark grey = Wants
                 red       = Conflicts
                 green     = After

Sehr schleierhaft das ganze... In der /etc/fstab sind die ganzen Einträge bzgl. der Backup-Mounpoints auskommentiert.

[EDIT]
Hier ein ausführlicheres log von einem weiteren Boot:
http://paste.debian.net/hidden/30a2e175/

Und noch ein paar spannende Zeilen vom nächsten Boot:

Code: Alles auswählen

[   29.064987] systemd[1]: Got direct mount request on /var/cache/backup, triggered by 1771 (mountpoint)
[   29.065009] systemd[1]: Trying to enqueue job var-cache-backup.mount/start/replace
[   29.065125] systemd[1]: Installed new job var-cache-backup.mount/start as 275
[   29.065132] systemd[1]: Installed new job var-cache-backup-snapshots-mailbackup.mount/start as 286
[   29.065137] systemd[1]: Installed new job dev-mapper-mars.device/start as 287
[   29.065153] systemd[1]: Installed new job systemd-cryptsetup@mars.service/start as 288
[   29.065157] systemd[1]: Enqueued job var-cache-backup.mount/start as 275
[   29.065161] systemd[1]: var-cache-backup.automount changed waiting -> running
[   29.065188] systemd[1]: Starting Cryptography Setup for mars...
[   29.065567] systemd[1]: About to execute: /lib/systemd/systemd-cryptsetup attach mars /dev/disk/by-uuid/8afdced6-8204-42f0-a4e6-adc9c759b762 /dev/disk/by-id/usb-_USB_DISK_Pro_0755023B012A-0:0 luks,tries=3,noauto,keyfile-size=2048,keyfile-offset=512
[   29.065916] systemd[1]: Forked /lib/systemd/systemd-cryptsetup as 1772
[   29.066114] systemd[1]: systemd-cryptsetup@mars.service changed dead -> start
[   29.066141] systemd[1]: Expecting device dev-mapper-mars.device...
[   29.066478] systemd[1772]: Executing: /lib/systemd/systemd-cryptsetup attach mars /dev/disk/by-uuid/8afdced6-8204-42f0-a4e6-adc9c759b762 /dev/disk/by-id/usb-_USB_DISK_Pro_0755023B012A-0:0 luks,tries=3,noauto,keyfile-size=2048,keyfile-offset=512

Vor allem die 1. Zeile

Got direct mount request on /var/cache/backup, triggered by 1771 (mountpoint)

bedeutet jetzt genau was? Hier scheint offenbar der Hund begraben zu liegen...


Und wie ich gerade feststelle, versucht Systemd beim Start alle automount-points zu mounten:

Code: Alles auswählen

systemctl|grep mount
...
home-use...Mountpoint.mount loaded failed failed    /home/user/Dir2/Dir2/Dir3/Mountpoint
....

[/EDIT]

lg scientific

[scientific]

Irgendwie hab ich ja die Befürchtung, es handelt sich um einen Bug... Denn wenn ein fstab-Eintrag (noauto,comment=systemd.automount) trotzdem beim Booten gemountet wird, ist das definitiv kein Feature.

[EDIT]
Ich habe es jetzt getestet:
Ein USB-Stik mit der UUID in der fstab eingetragen.
Einmal mit den Optionen "defaults,noauto"
Der Stick wird beim Booten nicht gemountet.

Dann mit den Optionen "comment=systemd.automount,defaults,noauto"
Der Stick wird beim Booten gemountet.

Soviel ich von systemd und automount mitbekommen habe, dürfte der dann aber nicht gemoutet werden. Also ein Bug.
[/EDIT]

Werde mal einen Bugreport verfassen.

[habakug]

Hallo!

Bevor du einen Bugreport schreibst, schau mal, ob es in der fstab nicht "nofail" statt "noauto" heissen muss.

Gruss, habakug

[scientific]

Auf http://www.freedesktop.org/software/sys ... mount.html ist es eindeutig "noauto"

noauto, auto
With noauto, this mount will not be added as a dependency for local-fs.target. This means that it will not be mounted automatically during boot, unless it is pulled in by some other unit. Option auto has the opposite meaning and is the default.

Das unit-File, welches mein systemd aufgrund des fstab-Eintrages erzeugt schaut so aus:

Code: Alles auswählen

root@debian: # cat /run/systemd/generator/mnt.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
After=local-fs-pre.target
Conflicts=umount.target
Before=umount.target

[Mount]
What=/dev/disk/by-uuid/0F02-77CB
Where=/mnt
Type=vfat
FsckPassNo=0
Options=defaults,noauto,comment=systemd.automount

Und trotzdem wird /mnt beim booten gemountet. Also ist es ein Bug. Denn die Abhängigkeit zu local-fs.target ist nicht vorhanden.

lg scientific

PS: bugreport ist draußen https://bugs.debian.org/cgi-bin/bugrepo ... bug=763751

[scientific]

Auf bugs.debian.org hab ich den Hinweis bekommen, mal nach "mountpoint" zu suchen. Das ist ein Programm, welches Verzeichnisse mit der FS-Tab vergleicht und als Rückgabe "ist ein Mountpoint" oder "ist kein Mountpoint" ausgibt. Dieses Programm wird von

Code: Alles auswählen

 /etc/init.d/mountnfs.sh

losgeslassen und rödelt sich durch alle Mountpunkte der fstab durch (und irgendwie auch offenbar durch die systemd-units... den Mechanismus hab ich noch nicht rausgefunden) und erzeugt damit Zugriffe auf die Automount-Punkte... die dann brav von systemd gemountet werden, weil ja ein Zugriff stattfand...

Ein unguter Mechanismus. Hab das auch so an den Bugreport weitergemeldet.

Jetzt hab ich zumindest einmal den Schuldigen dingfest gemacht, aber noch keine Lösung, um ihm Herr zu werden.

Und ich würde mich voll freuen, wenn ich da noch ein wenig fachkundigere Unterstützung finde

lg scientific

[smutbert]

Nachdem das aber nur für nfs ist (ich mutmaße einmal, dass du nfs gar nicht verwendest), sollten doch keine Probleme entstehen, wenn du das Skript lahmlegst indem du die Links auf dieses Skript löscht. Bei mir wären das

Code: Alles auswählen

/etc/rc0.d/K03umountnfs.sh 
/etc/rcS.d/S13mountnfs.sh
/etc/rc6.d/K03umountnfs.sh
/etc/rcS.d/S14mountnfs-bootclean.sh

oder das Skript vorübergehend aus dem Weg räumst und durch ein kurzes

Code: Alles auswählen

#! /bin/sh
### BEGIN INIT INFO
# Provides:          mountnfs
# Required-Start:    $local_fs
# Required-Stop:
# Should-Start:      $network $portmap nfs-common  udev-mtab
# Default-Start:     S
# Default-Stop:
# Short-Description: Wait for network file systems to be mounted
# Description:       Network file systems are mounted by
#                    /etc/network/if-up.d/mountnfs in the background
#                    when interfaces are brought up; this script waits
#                    for them to be mounted before carrying on.
### END INIT INFO

/bin/true

oder etwas ähnliches ersetzt ☺
Dann wäre zumindest einmal klar ob das Skript wirklich die Ursache ist…



…was ich andererseits fast für unwahrscheinlich halte:

Code: Alles auswählen

…
while read DEV MTPT FSTYPE OPTS REST; do
                                case "$DEV" in
                                  ""|\#*)
                                        continue
                                        ;;
                                esac
                                case "$OPTS" in
                                  noauto|*,noauto|noauto,*|*,noauto,*)
                                        continue
                                        ;;
                                esac
                                case "$FSTYPE" in
                                  nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs|ceph)
                                        ;;
                                  *)
                                        continue
                                        ;;
                                esac
                                case "$MTPT" in
                                  /usr/local|/usr/local/*)
                                        ;;
                                  /usr|/usr/*)
                                        waitnfs="$waitnfs $MTPT"
                                        ;;
                                  /var|/var/*)
                                        waitnfs="$waitnfs $MTPT"
                                        ;;
                                esac
                        done < "$file"
…

das ist jetzt nur ein Ausschnitt, aber wenn die Mountoptionen noauto oder etwas ähnliches enthalten, kommt das continue, er springt also gleich an den Anfang des nächsten Schleifendurchgangs und bearbeitet die nächste Zeile der fstab. Damit dürfte er gar nie zu dem letzten case kommen, in dem er vielleicht lesen auf die Mountpoints zugreift…

[scientific]

Ich hab den Schuldigen gefunden. Und auch einen wirksamen Patch geschrieben.

Code: Alles auswählen

--- sysvinit-2.88dsf/debian/src/initscripts/lib/init/mount-functions.sh	2013-07-14 19:19:01.000000000 +0200
+++ /lib/init/mount-functions.sh	2014-10-04 12:10:55.377855961 +0200
@@ -215,6 +215,12 @@ domount () {
 	    DEVNAME=$FSTYPE
 	fi
 
+	case "$DEVNAME" in
+		systemd-1)
+			return
+			;;
+	esac
+
 	# Get the mount options from /etc/fstab
 	if read_fstab_entry "$MTPT" "$FSTYPE"; then
 		case "$MNT_OPTS" in

Das init-Skript /lib/init/mount-functions.sh war noch nicht auf systemd getrimmt und hat den Eintrag in der mtab für systemd.automounts "systemd-1" einfach nicht berücksichtig...

Hier getestet und es funktioniert.

Mein erster Pach in Debian. Hab auch einen Bugreport an initscripts verfasst. Bin gespannt, wie schnell das berücksichtigt wird.

lg scientific