Jessie Upgrade mit Problemen Systemd / Sysvinit

[Celica]

Folgendes steht jetzt (kein Laufwerk gemounted) in der "/var/run/systemd/generator/":

Code: Alles auswählen

/var/run/systemd/generator$ ls
boot-efi.mount                                                             mnt-yaVDR1ShareVDR.mount      multi-user.target.wants
dev-disk-by\x2duuid-168572f2\x2d6c11\x2d461a\x2db286\x2d4749b6f05ca4.swap  mnt-yaVDR1Video.mount         networking.service.d
home.mount                                                                 mnt-yaVDR2.mount              remote-fs.target.d
hwclock.service.d                                                          mnt-yaVDR2Video.mount         rpcbind.service.d
local-fs.target.requires                                                   -.mount                       rpcbind.target.d
local-fs.target.wants                                                      mountall-bootclean.service.d  sendsigs.service.d
media-cdrom0.mount                                                         mountall.service.d            swap.target.wants
mnt-Netbook.mount                                                          mountnfs-bootclean.service.d  umountfs.service.d
mnt-T410.mount                                                             mountnfs.service.d            umountnfs.service.d

Das sind unter anderem die Laufwerke, die ich händisch in die "fstab" dazu gefügt habe:

Code: Alles auswählen

#NFS Laufwerke
192.168.1.8:/home/christopher   /mnt/Netbook    nfs     user,noauto,timeo=14,soft,intr    0 0
192.168.1.6:/home/martina/       /mnt/T410    nfs     user,noauto,timeo=14,soft,intr		0 0
192.168.1.2:/srv/video/   /mnt/yaVDR1Video    nfs     user,noauto,timeo=14,soft,intr    0 0
192.168.1.2:/srv/share/vdr   /mnt/yaVDR1ShareVDR    nfs     user,noauto,timeo=14,soft,intr    0 0
192.168.1.4:/srv/share/vdr/	/mnt/yaVDR2/	nfs		user,noauto,timeo=14,soft,intr		0 0
192.168.1.4:/srv/video/	/mnt/yaVDR2Video/	nfs	user,noauto,timeo=14,soft,intr		0 0

Ich gestehe, dass ich gerade nicht ganz durchblicke.

Habe aus einem anderen Beitrag von Stephan, da ging es aber seiner Zeit um die Server Seite, folgende Info erhalten:

In diesem Thread ging es ursprünglich um die NFS Server Seite.
Du meinst jetzt aber fehlgeschlagene mounts von der Client Seite, right?

Falls ja:

Ist der seit Ewigkeiten bekannte und bis heute offensichtlich nicht gefixte Bug #540291.
Abhilfe, die bei mir funzt:

1. In /etc/fstab alle nfs Einträge mit noauto versehen

2. Neues Script /etc/network/if-up.d/bugfix-nfs-mount

Code: Alles auswählen

Code: Alles auswählen
    #!/bin/sh -e
    #
    # /etc/network/if-up.d/bugfix-nfs-mount
    #
    # Workaround für Fehler im automatischen NFS-Mount (Bug #540291)
    # Falls der Test auf ein vorhandenes Netzverzeichnis fehlschlägt:
    # versuchen es nochmal nachträglich zu mounten

    if [ "$IFACE" != "lo" ] && [ ! -d "/server/user/root" ]; then
        mount -an
    fi
    exit 0

Gruß
Stephan

Da wird von einem Bug gesprochen und ein Workaround über ein Script realisiert.

Ich verstehe es halt nur nicht, da ja alles wunderbar funktioniert.

Wie gesagt: Ich möchte es richtig machen und vor alles verstehen.

[Celica]

Also für mich ist das Thema noch nicht geklärt, wenn gar derzeit alles funktioniert.
Wäre schön wenn das noch zu ende gebracht werden könnte.

[TomL]

Da wird von einem Bug gesprochen und ein Workaround über ein Script realisiert. Ich verstehe es halt nur nicht, da ja alles wunderbar funktioniert. Wie gesagt: Ich möchte es richtig machen und vor alles verstehen.

Dein Problem ist, dass Dir momentan noch die Erfahrung fehlt, zwischen Alt und Neu zu unterscheiden. Und deswegen tappst Du in die Falle, alten HowTo's oder Ratschlägen zu folgen, welche solcherart Debian-Probleme lösen, die es heute so unter Systemd gar nicht mehr gibt. Das perfide ist, dass diese alten Lösungen zum Teil dann doch wieder zu aktuellen Lösungen werden, weil vorher systemd-Funktionalität so umgebogen wurde, dass systemd wieder sysvinit-Konform ist ... dabei braucht man das gar nicht.

Also.... früher, vor der aktuellen Debian-Version "Jessie" gabs die Version "Wheezy". Der wirklich markante und absolut maßgebliche Unterschied zwischen diesen beiden Versionen begründet sich durch den Wechsel des Start-Systems von sysvinit zu systemd. Das bedeutet, ein früher starrer und linear ablaufender Bootvorgang, der über 100e von speziellen (durch den Laien undurchschaubaren) Wrapper-Scripten in /etc/init.d supportet wurde, die zudem m.E. ziemlich kompliziert in die RunLevel-Dirs gesymlinkt wurden, wurde ersetzt durch einen parallel startenden Bootvorgang, der darauf abzielt, keine Wrapper-Scripte mehr zu verwenden. Keine Wrapper-Scripte bedeutet, dass in der künftigen Version "Stretch" das Verzeichnis "etc/init.d" so gut wie leer ist.... ich sag dazu "gottseidank!". RedHat-Fedora hat es mittlerweile ganz abgeschafft.... und ich bin sicher, dass Debian das auch tun wird. Mit diesem Schritt ist der gesamte Bootvorgang für mich als Laie bedeutend transparenter und leichter nachvollziehbar geworden.

Soviel als erstes... nun die Mount-Units. Mount-Units sind heute unter systemd obligatorisch. Das bedeutet, jeder Mount wird immer über eine Mount-Unit durchgeführt. Da die fstab aber weiterhin erklärtes und etabliertes Objekt für Mounts bei systemstart ist und bleiben soll, bedarf es eines automatischen Generators, der die fehlenden Mount-Units für die fstab-Einträge erzeugt, wenn die fstab bearbeitet wird. Das macht systemd automatisch. Diesen Vorgang kann man aber umgehen, in dem man einfach selber eigene und optimal eingestellte Mount-Units einrichtet. Das ist für lokale Laufwerke allerdings nicht notwendig, das funktioniert mit dem AutoGen perfekt. Problematisch ist es aber auf Grund des parallelen Systemstarts evtl. für Netzwerk-Laufwerke. Weil es da passieren kann, dass die fstab-Bearbeitung (wegen der lokalen Laufwerke) vor dem erfolgreichen Start (und der Verbindung) des Netzwerkes erfolgen kann. Das bedeutet evtl., der Mount der NAS-Laufwerke failed. Üblicherweise setzen dann da solcherart Scripts wie bei dem "alt-bug-Ratschlag" an, die zudem auch noch auf den GoodWill eines Network-Managers beruhen und darüberhinaus seiner Willkür über dessen Defnition des Netwerkstatus unterliegen. Das heisst, unterschiedliche Distris = möglicherweise unterschiedliche NetMan-Implementierung = unvorhersagbare Definition des Netzwerkstatus = merkwürdige Probleme beim Mount = Rückgriff auf noch merkwürdigere Lösungsvorschläge.

Gerade was den Network-Manager angeht ist mit einem weiteren Problem zu rechnen, und zwar diesen typischen und auch lange bekannten und sehr ärgerlichen Stop-Job-Effekt bei Remote-Mounts über ein WLAN-Nic.Bis heute unter Jessie kloppt der NM einfach die WLAN-Verbindung weg, in dem er vermutlich planmäßig den Daemon wpasupplicant beendet ... dieser Daemon ist für die WLAN-Verbindung an sich zuständig. Nur besteht da das (auch alte) Problem, dass dann die vorhandenen Mounts nicht mehr unmountet werden können, was systemd minutenlang erfolglos beim Poweroff versucht, um darüber wiederum den Shutdown minutenlang zu blockieren. All das kann man bei den Remote-Mounts einfach vermeiden, in dem man eigene Mount-Units erzeugt, die ggf. nach einer weiteren service-unit starten, welche den gewünschten Server "als verfügbar" markiert. Ganz automatisch ist damit auch das o.g. Shutdown-Problem behoben.

Und als drittes und letztes.... zu Deinem Posting in dem Bind-Problem-Thread. Man muss hier die Perspektiven auf eine bestimmte Ressource unterscheiden. Für den Server ist eine bestimmte Festplatte eine lokale Festplatte, die regulär und völlig problemlos über die fstab gemountet wird und deren Festplattenverzeichnisse darüber hinaus und weitergehend separierend ge'bind'et werden können. Mit diesen Bind's können z.B. Unterverzeichnisse der Festplatte als eigene Mountpoints im Server-Dir /media oder /mnt erstellt werden, die dann wieder als "Remote-Platte" von einem Client-PC gemountet werden können. Also, für den Server ist die Platte eine lokal angeschlossen Platte, für den Client ist es eine Remote-Ressource.... beiden ist gemein, dass -egal wie und wohin- auf jeden Fall Mount-Units bestehen, wenn die Platte/Verzeichnisse gemountet ist.

Mein Fazit:
Wenn es jetzt mit Deinem Rechner läuft, würde ich nix ändern. Du musst nur im Hinterkopf behalten, dass diese Lösung nicht unbedingt genau so stabil läuft, wenn sich Rahmenbedingungen ändern, oder wenn Du z.B. einen 'Raspberry Pi 3' via WLAN einsetzen möchtest, oder einen Laptop/Notebook in einem Raum mit eher schlechterem WLAN-Empfang. Dann würde ich bei der Lösungsfindung definitiv keine alten "Krücken" verwenden, sondern eine eindeutig systemd-orientierte Lösung einrichten.

Wenn noch Fragen sind.... frag einfach noch mal.... aber als RundUmBlick müsste das jetzt eigentlich reichen.....

Hth

[scientific]

All das kann man bei den Remote-Mounts einfach vermeiden, in dem man eigene Mount-Units erzeugt, die ggf. nach einer weiteren service-unit starten, welche den gewünschten Server "als verfügbar" markiert.

NetworkManager ist in der Tat ein super und gleichzeitig mistiges Stück Software. Ich verwende ihn, obwohl sogar schon sich ändernde WLAN-Verbindungen mit systemd und wpa_supplicant verwaltet werden können, weil ich gelegentlich über USB-Thetering mein Handy als Modem verwende, oder tatsächlich UMTS/LTE-Sticks in Verwendung habe und dazu der ModemManger von NetworkManager notwendig ist (für komfortables Bedienen). Außerdem ist der NetworkManager gut in Gnome integriert.

Das Problem ist, dass das "network-online.target" einmal gestartet immer aktiv bleibt. Selbst wenn die Verbindung abbricht oder bewusst beendet bleibt.

Ich hab mir ein dispatcher-Skript für NetworkManager geschrieben, welches jede Minute prüft, ob der NetworkManager eine aktive Verbindung hat und ob die Verbindung auch tatsächlich funktioniert (ping an google). Sollte das nicht der Fall sein, wird der NetworkManager neu gestartet. Hat der NetworkManager keine aktive Verbindung, oder wird die aktive Verbindung beendet, stoppt das dispatcher-Skript das network-online.target (und startet es wieder, sobald NetworkManager erneut eine aktive Verbindung aufgebaut hat).

Ich hab fetchmail, sshd und andere Dienste und an network-online.target gebunden (BindsTo=network-online.target), welche mit der tatsächlichen Netzwerkverbindung gestartet und gestoppt werden.

Wie löst du das mit der Unit, die anzeigt, ob ein Server erreichbar ist?

lg scientific

[rendegast]

All das kann man bei den Remote-Mounts einfach vermeiden, in dem man eigene Mount-Units erzeugt, die ggf. nach einer weiteren service-unit starten, welche den gewünschten Server "als verfügbar" markiert. Ganz automatisch ist damit auch das o.g. Shutdown-Problem behoben.

In den vom generator erzeugten Units für nfs steht ganz valide
Type=nfs
Das sollte auch systemd reichen, ohne irgendwelche Abwarte-units zwischenschalten zu müssen.
Wie hierüber geschildert liegt das Problem bei einem work-in-progress network-manager.

... der über 100e von speziellen (durch den Laien undurchschaubaren) Wrapper-Scripten in /etc/init.d supportet wurde, die zudem m.E. ziemlich kompliziert in die RunLevel-Dirs gesymlinkt wurden, wurde ersetzt durch einen parallel startenden Bootvorgang, der darauf abzielt, keine Wrapper-Scripte mehr zu verwenden. Keine Wrapper-Scripte bedeutet, dass in der künftigen Version "Stretch" das Verzeichnis "etc/init.d" so gut wie leer ist....

/lib/systemd/ ist nicht gerade durchschaubarer.
Sollte der von Dir geschilderte optimale Zustand erreicht sein,
ganz einfache unit, in denen eigentlich nur steht 'Exec=programm', weil programm sich seine Konfig komplett woanders her holt,
so würde/sollte auch das entsprechende init.d/-Skript mit einem einfachen
'start-stop-daemon --start --exec programm'
auskommen.

[TomL]

Wie löst du das mit der Unit, die anzeigt, ob ein Server erreichbar ist?

Über eine neue Unit, die ich ebenso wie das Programm dazu 'network_wait_online' genannt habe. Es passiert nix anderes, als das durch das Statement 'Before=network-online.target' das reguläre network-online.target erst dann angezogen wird, wenn das Netz tatsächlich erfolgreich verbunden ist. Das heisst, alle anderen Service-Units, die auch after network-online.target verwenden, finden damit ebenfalls das erfolgreich verbundene Netzwerk vor. Gleichzeitig sollte damit verhindert sein, dass die aktive (!) Unit network-online.target gleich mehrere Wait-State-Instanzen etabliert, welche jeweils "substantial delays" beinhalten, wenn sie mehrfach angezogen wird. Das warten ist nicht eine statische Zeit lang, sondern tatsächlich nur so lange, bis der Server/Host wirklich erreichbar ist.

Zurrst das Programm anlegen:

Code: Alles auswählen

nano /usr/local/bin/network_wait_online

Code: Alles auswählen

#!/bin/bash

[ -z "$1" ] && Server="8.8.8.8" || Server=$1
sec=0
HomeNetIsConnect=-1

while [ true ]; do
    /bin/ping -c1 -W1 -q $Server &>/dev/null
    HomeNetIsConnect=$?

    [ $sec -eq 90 ] || [ $HomeNetIsConnect -eq 0 ] && break

    sec=$[$sec+1]
    /bin/sleep 0.5
done

if [[ $HomeNetIsConnect -eq 0 ]]; then
    echo "Host $Server is reachable! (RC:$HomeNetIsConnect, after $sec Seconds wait)" | systemd-cat -t "`basename $0`" -p "info"
    exit 0
fi

echo "Host $Server is not reachable! (RC:$HomeNetIsConnect, after $sec Seconds wait)" | systemd-cat -t "`basename $0`" -p "err"
exit 1

Und dann für dieses neue Script eine Service-Unit installieren, in dem entweder auf die zu wartende Server-IP oder auf die des Routers gewartet wird. Dazu muss natürlich die IP 10.20.30.1. in der Service-Unit durch die richtige IP ersetzt werden, hier durch die eines Routers oder eines Servers, der die Remote-Laufwerke zur Verfügung stellt.

Code: Alles auswählen

nano /etc/systemd/system/network_wait_online.service

Code: Alles auswählen

[Unit]
Description=network_wait_online.service:   Waiting for Network or Server to be up
DefaultDependencies=no
After=network.target
Before=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=95
ExecStart=/usr/local/bin/network_wait_online 10.20.30.1

[Install]
WantedBy=multi-user.target

Dann noch für Script und Unit die Rechte setzen: root:root für beide, 644 für die Unit und 755 für das Programm und die Unit aktivieren, starten und die Fehlemeldungen kontrollieren:

Code: Alles auswählen

systemctl daemon-reload
systemctl enable network_wait_online.service
systemctl start network_wait_online.service
systemctl status network_wait_online.service

Ab jetzt kann man in die eigenen Mount-Units

Code: Alles auswählen

Requires=network-online.target
After=network-online.target

oder

Code: Alles auswählen

Requires=network_wait_online.service
After=network_wait_online.service

eintragen, oder das einfach auch direkt in die fstab-mount-options übernehmen:

Code: Alles auswählen

x-systemd.requires==network_wait_online.service

[TomL]

Sollte der von Dir geschilderte optimale Zustand erreicht sein, ganz einfache unit, in denen eigentlich nur steht 'Exec=programm', weil programm sich seine Konfig komplett woanders her holt, so würde/sollte auch das entsprechende init.d/-Skript mit einem einfachen
'start-stop-daemon --start --exec programm'auskommen.

Ich habe jetzt hier 3 ganz einfache Beispiele, an denen man erkennen kann, wie sinnlos und unnötig der frühere überfette init.d-Overhead war und was jetzt davon alles total überflüssig ist..... also Binary und zusätzlich dazu noch Start-Scripte plus deren SymLinks in bis zu 8 RunLevel-Dirs, in Summe verzichte ich jetzt auf 18 oder 20 vollkommen unnötige Dateien. Das Ein- und Ausschalten von Services oder deren Umpositionierung geht heute in jeder Hinsicht einfachst und deutlich schneller. Und gerade die von OpenVPN traditionell angelegte Datei-Orgie in /etc lässt mich heute nur noch fassungslos staunen, wenn ich daran denke, dass ich aktuell für OpenVPN nur noch das Binary benötige, also nur noch zwei Dateien, das Binary in /usr/bin anstelle von haufenweisen Script und Confs - und natürlich diese eine Unit.

Code: Alles auswählen

[Unit]
Description=Wireless network connectivity (Interface=wlan0)
Wants=network.target
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/sbin/ip link set dev wlan0 up
ExecStart=/sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wifi.conf
ExecStart=/sbin/dhclient wlan0
ExecStop=/sbin/ip link set dev wlan0 down

[Install]
WantedBy=multi-user.target

Code: Alles auswählen

[Unit]
Description=thlu:luks-container.service:   Open local Luks-Container
DefaultDependencies=no
After=local-fs.target
ConditionPathExists=/home/usb/.CryptCredentials

[Service]
Type=forking
RemainAfterExit=yes

ExecStartPre=/sbin/losetup /dev/loop0 /media/secrets/storage.vol
ExecStartPre=/sbin/cryptsetup luksOpen /dev/loop0 storage --key-file "/home/usb/.CryptCredentials"
ExecStart=/bin/mount /dev/mapper/storage /mnt -t ext4 -o rw   

ExecStop=/bin/umount /dev/mapper/storage -f
ExecStopPost=/sbin/cryptsetup luksClose storage
ExecStopPost=/sbin/losetup -d /dev/loop0

[Install]
WantedBy=multi-user.target

Code: Alles auswählen

[Unit]
Description=thlu:openvpn.service   OpenVPN TCP Client 443
After=syslog.target network.target systemd-networkd-wait-online.service

[Service]
Type=forking
PIDFile=/var/run/openvpn/tcp443.pid
ExecStartPre=/bin/mkdir -p /var/run/openvpn
ExecStart=/usr/local/sbin/openvpn --daemon --writepid /var/run/openvpn/tcp443.pid --status /var/run/openvpn/tcp443.status 60 --cd /etc/openvpn/ --config /etc/openvpn/tcp443.conf
KillMode=process

[Install]
WantedBy=multi-user.target

Und was die Transparenz des Bootens angeht, zeig mir bitte eine äquivalente Funktion zu

Code: Alles auswählen

systemd-analyze plot >~/bootplot.svg

die gleich als Werkzeug on board dabei ist.

Für mich ist der Vergleich von sysvinit und systemd dasselbe, wie ein Vergleich zwischen eisenbeschlagenem Holzrad und einem modernen Luftreifen. Aber dennoch muss man anerkennen, beide funktionieren, beide rollen, beide kann man unter einen Karren schrauben.... tja...

[rendegast]

Ich habe jetzt hier 3 ganz einfache Beispiele,

Selbst da ist noch viel zuviel Gelumpe.

ExecStart=/usr/local/sbin/openvpn --daemon --writepid /var/run/openvpn/tcp443.pid --status /var/run/openvpn/tcp443.status 60 --cd /etc/openvpn/ --config /etc/openvpn/tcp443.conf

optimal

Code: Alles auswählen

ExecStart=/usr/local/sbin/openvpn

Und was die Transparenz des Bootens angeht, zeig mir bitte eine äquivalente Funktion zu
systemd-analyze plot >~/bootplot.svg

Für diese Einfachheit für ein bootplot muß ein Bildgenerator eingebaut sein.
Wohl nötig wegen der unerklärlichen x*30s-Timeouts beim Booten

[TomL]

In den vom generator erzeugten Units für nfs steht ganz valide
Type=nfs
Das sollte auch systemd reichen, ohne irgendwelche Abwarte-units zwischenschalten zu müssen.

Da habe ich eine vollkommen andere Meinung. Warum sollte sich systemd überhaupt um solche Parameter kümmern? Das ist imho allein eine Sache der Mount-Programme und in Folge dessen des Kernels, der den Mount dann durchführt. Ich denke, dass sich systemd überhaupt nicht darum kümmert oder sich darum zu kümmern hat, sondern lediglich auf den Rückkehrstatus der Programme reagiert... wo imho auch genau seine Verantwortung beginnt oder endet. Der Parameter Type=nfs hat meiner Meinung nach keinen anderen Zweck als den passenden Mount-Helper auszuwählen.

Code: Alles auswählen

ExecStart=/usr/local/sbin/openvpn

Ja, das geht in der Unit genauso, wenn man den ganzen vorher zu customizenden Overhead in /etc vorhält. Aber eben genau auf diesen Overhead verzichte ich gerne... was sich dann in der Folge sehr positiv auch in wesentlich vereinfachten Backup-Scripts zur System-Sicherung wiederspiegelt. Und diese Pre-Execs brauche ich, da bei mir /var/run = tempfs ist.

Wohl nötig wegen der unerklärlichen x*30s-Timeouts beim Booten

Das verstehe ich nicht.... ich kenne so etwas auch nicht, sondern führe das darauf zurück, was ich bereits oben gesagt habe: wenn alte Lösungen wieder zu aktuellen Lösungen werden, weil man systemd zu sysvinit zurückverbogen hat.... genau dann passieren diese Timeouts beim Booten oder diese StopJobs beim Shutdown. Wie gesagt, ich kenne so etwas allerdings nicht mehr, seitdem ich kompromisslos alle init.d-Scripte durch Service-Units ersetze, die ich für meine Prozesse ersetzen kann.

[scientific]

Ja diese Timeouts kenne ich auch nicht mehr. Habe ebenfalls nach bestem Wissen div. init-skripte durch native systemd-units ersetzt, nachdem ich studierte, wie was genau die init-skripte machen.

Wenn jetzt etwas hängt, dann ist es der Haussegen, und der hängt schief, wenn ich zuviel am Computer herumwerke
Aber gelegentlich möchte zeitgeist-datahub nicht sterben und manchmal auch der evolution-data-server. Ab und zu mal hängt ein unmount meiner externen Festplatte, das aber wohl immer mit einem zu unterbrechenden btrfs scrub/balance zusammenhängt, das immer noch nicht vernünftig abgebrochen werden kann.

Ich hab jetzt einzig noch beim booten einen ACPI-Hänger von 6 Sekunden, wo ich gerade mit den Kernel-Entwicklern per Bug-Report in Kontakt bin. Ansonsten ist mein Rechner ab UEFI bis zum GDM-Login in 10 (derzeit 16 wegen des ACPI-Hängers) da. Mit gestartetem Mailserver (dovecot/exim) und div. anderen Diensten incl. btrfs-snapshot nach erfolgreichem Booten und einem ersten Mailabruf mit bogofilter.

SSD und systemd sei Dank

Ich hab das bootchart

Code: Alles auswählen

systemd-analyze plot > bootchart.svg

sorgfältig durchforstet und fragliche/langsame Dienste bzgl. Start analysiert.
Problemfälle waren einerseits der NetworkManager (mit ModemManager und anderen davon abhängigen Komponenten und Diensten), die einer klapprigen Billig-WLAN-Karte des Laptops geschuldet waren (und einem WLAN im dichtverbauten städtischen Gebiet mit vielen Interferenzen... mittlerweile klappt es mit einer neuen WLAN-Karte) und Diensten die über generator-units noch die alten init.d-Skripte nutzten.
Dabei waren häufig div. Abfragen ob der Rechner am Netz hängt oder im Akkubetrieb läuft beteiligt... Die kann man alle mit einer Condition in systemd-units abfangen.
Und ich hab ein wenig an den Abhängigkeiten der Units untereinander geschraubt. Damit starteten die viel (bis zu 5 Sekunden) schneller, was bei einer Bootzeit von 30 Sekunden schon 1/6 ausmacht...

Aber im Endeffekt waren die meisten Verzögerungen beim Boot dem instabilen WLAN geschuldet. Seit ich die Karte getauscht habe, gibts diese Verzögerungen nicht mehr.

Ein weiterer Bremsfaktor ist die unit NetworkManager-wait-online.service. Die soll man nur aktivieren, wenn man Dienste hat, die von einer funktionierenden Netzwerkverbindung abhängen. Mein Eindruck ist aber, dass dieser Service nicht besonders gut durchdacht ist und schon gar nicht für Laptop-User gebaut wird. Ich weiß nicht, ob der von den Machern von systemd kommt oder von Debian-Maintainern. Jedenfalls ist es äußerst unlogisch 5 (oder sinds im Original 30?) Sekunden zu warten, ob der NetzwerkManager online ist und dann aktiv zu bleiben, egal was mit der Netzwerkverbindung ist.

Mein Dispatcher-Skript schaut so aus:

Code: Alles auswählen

#!/bin/bash
if /usr/bin/nm-online --timeout 5; then
  /bin/systemctl start network-online.target
else
  /bin/systemctl stop network-online.target
fi

exit 0

Bei jeder Veränderung von Netzwerkverbindungen wird es so gestartet. Damit testet es, ob der Netzwerk-manager online ist und startet odet stoppt in Abhängigkeit vom Ergebnis das network-online.target. Damit hab ich eine Unit an die ich div. Dienste hängen kann, die von einer aktiven Netzwerkverbindung abhängig sind. Z.b. mounts für externe ftp-Server. Ich hänge die aber nicht direkt mit einer Mount-Unit ein, sondern mit einer Automount-unit, die nach einem Timeout die Source wieder aushängt.
Sollte also die Netzwerkverbindung flöten gehen, wird die automount-unit gestoppt. Ich kann z.b. mittels ls dann trotzdem das Verzeichnis anzeigen lassen, ohne dass das System in ein Timeout mit Fehler läuft, weil die Source nicht eingehängt ist, obwohl sie es sein sollte.

Eine solche automount-Unit sieht z.B. so aus:

Code: Alles auswählen

 cat /etc/systemd/system/home-jakob-.aptly-ftp.automount
# /run/systemd/generator/home-jakob-.aptly-public.automount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
PartOf=network-online.target

[Automount]
Where=/home/jakob/.aptly/ftp
TimeoutIdleSec=10s

[Install]
WantedBy=network-online.target

Greife ich nun auf /home/jakob/.aptly/ftp zu (z.B. mittels unison), wird der FTP-Server eingehängt und mit /home/jakob/.aptly/publish synchronisiert. Nach 10 Sekunden nach dem Ende der Aktion, wird der Server wieder ausgehängt. Ich komm nicht in die Verlegenheit, dass ich einem aufrechten Mount eines FTP-Servers die Netzwerkverbindung unter dem Boden wegziehe und beim Runterfahren ein Timeout von 90 Sekunden produziere...

Das PartOf bewirkt, dass bei enableder Unit automount am Mountpoint mit network-online.target von oben gestartet und gestoppt wird.

lg scientific

[Celica]

Puh und wow.
Vielen herzlichen Dank für die ganzen Infos von euch.
Ich werde darauf zurück kommen, aber das dauert ein paar Tage, da ich in Ausland auf Geschäftsreise bin und nur kurz drüber fliegen konnte.
Ich werde wenn ich wieder zu hause bin, mir alles genau durch lesen und mich dazu melden.
Das ist wieder einer der Momente warum ich Open Source, Debian und dieses Forum mit den Mitgliedern hier mag.