Jessie Upgrade mit Problemen Systemd / Sysvinit

[DeletedUserReAsG]

So überflüssig ist der Parameter in bestimmten Situationen nicht.

Ansonsten würde ich auch sagen, dass ein sauberes Neuaufsetzen vielleicht Zeit und Nerven spart.

[Celica]

Alles gut. Danke. War ein Versuch wert.
Sollte da nicht noch ein Wunder geschehen, dann werde ich nächste Woche den Rechner einmal neu machen.

Fühlt sich einfach sauberer an
In der Hoffnung eine Investition in die Zukunft zu machen.

Eine Frage hätte ich noch: Ich hatte seiner Zeit mit UEFI zu kämpfen. Nicht das hier der Hund begraben ist.

[Taomon]

Der Befehl kann auch nix bewirken, war nur eine Simulation, da ich wie geschrieben die Pakete nicht drauf habe und die Abhängigkeiten nicht kenne.

Code: Alles auswählen

apt purge libsystemd-daemon0:amd64 libsystemd-login0:amd64 

Code: Alles auswählen

apt update && apt full-upgrade

Gruß Taomon

[Celica]

Letzteres hatten ich schon.
Wie schaut das mit UEFI aus?

[maledora4]

Wie schaut das mit UEFI aus?

Rein von der Logik her, ist die EFI doch weit "vor systemd/sysvinit" 'dran.

[Celica]

Hallo,

hatte gestern meinen Rechner dann neu aufgesetzt. War kein Problem. /home hatte ich dannn nach der Installation eingebunden und alles gut. Die alten Konfig Dateien konnte ich 1:1 wieder nutzen, Profile für Icedove und Iceweasel ebenso. Damit war das System ganz schnell wieder am Start.

Was ich aber herausgefunden habe: Bei dem Versuch meine NFS-Laufwerke wieder über die "fstab" einzubinden, hat sich exakt der gleiche Fehler eingestellt wie bei dem Upgrade von Wheezy zu Jessie. Der Start ist beim Eingabeprompt für Maintenance hängen geblieben.

Kurz überlegt was ich zuletzt konfiguriert hatte und dann bin ich auch drauf gekommen. Die NFS-Laufwerke in der "fstab" sind der Fehler. Das kann ich reproduzieren !

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/   user,noauto,timeo=14,soft,intr      0 0

Das habe ich schon in einem anderen Beitrag viewtopic.php?f=12&t=163604&p=1116391#p1116391 gepostet, da ich gerade keine Ahnung habe wie das in Jessie funktioniert die NFS-Laufwerke via AutoFS zu mounten.
Da gibt es ein Problem bzw. funktioniert das anders.

Meiner Meinung nach komplizierter und nicht wirklich Benutzerfreundlich, aber vielleicht klärt sich das auch noch.

Vielleicht habt Ihr eine Idee, oder sagt wie ihr das für euch gelöst habt.

Jedenfalls kann ich mit 99,9% Sicherheit sagen was mein eigentliches Problem gewesen ist bei dem Upgrade.
Damit ist eigentlich alles richtig gelaufen, nur habe ich nicht die NFS-Laufwerke auf dem Schirm gehabt.
Sicherlich auch irgendwo beschrieben, aber so tief stecke ich nicht in der Materie.

[TomL]

Das habe ich schon in einem anderen Beitrag viewtopic.php?f=12&t=163604&p=1116391#p1116391 gepostet, da ich gerade keine Ahnung habe wie das in Jessie funktioniert die NFS-Laufwerke via AutoFS zu mounten.

Mich wundert, wenn Du für Dich selber feststellst, dass Du "keine Ahnung von den Jsessie-Funktionalitäten hast" und gleichermaßen feststellst, dass eine unmittelbare systemd-Methode unter systemd "untauglich" oder "benutzerunfreundlich" ist. Es gibt natürlich verschiedene alternative Möglichkeiten, das zu lösen, auch welche, die ohne systemd funktionieren:

1. systemd deinstallieren und stattdessen wieder sysvinit zu verwenden. Da gibt es hier einen Fachmann für. Ob diese Lösung dann aber noch unter Stretch läuft ist für mich erst mal fraglich.
2. Jessie deinstallieren und dafür Wheezy installieren. Dann läuft auch wieder sysvinit. Wheezy hat noch bis 05.2018 LTS-Support
3. Einfach die vorgeschlagene Mount-Unit erstellen, mehrfach kopieren und das Problem als gelöst abhaken
4. Ein Script erstellen, welches die Mounts in Abhängigkeit der Netzwerkverfügbarkeit durchführt
5. Den zweifelhaften Versuch starten, mit einem Sleep 'sowieso' den Bootprozess zu blockieren und die Mounts in der rc.local durchzuführen, wobei da wieder die Möglichkeit besteht, dass es die rc.local in Stretch gar nicht mehr geben wird.
6. Die Mounts als Pam-Mount einzustellen, die durch/mit der User-Anmeldung erfolgen
7. Jeden einzelnen Mount in der fstab mit einem Requires-Boot-Blocker versehen, wie der aktiven network-online.target... wobei da nicht ganz klar ist, wie und wann der Network-Manager "Network is up" definiert.

[Celica]

OK, Sarkasmus verstanden ! Danke für den Hinweis

Ja, ich bin nur ein Mensch der privat Linux benutzt und auf Debian schwört ... und das schon recht lange.
Ich bin kein Profi (ganz, ganz weit weg davon!) und habe auch beruflich nicht`s damit zu tun.
Einfach nur interessiert an freier Software und dem drum herum.

... und ja, eine andere Distribution wäre für mich vielleicht besser geeignet die einem mehr abnimmt und mir das Leben einfacher macht, aber: Genau das war seiner Zeit der Grund warum ich von Suse & Co. über Red Hat (seiner Zeit) zu Debian gekommen bin. Ich wollte einfach mehr lernen.
... und ja, ich lerne jeden Tag und mit jeder Version neues. Das macht es auf der einen Seite nicht immer ganz einfach für mein Umfeld (in dem Fall die Menschen hier im Forum) und mich, aber es macht auch Spaß.
... und ja, die Einleitung und der vorzeitige Fazit waren vielleicht nicht ganz richtig, da Systemd ja eigentlich gearbeitet hat und Debian hier keine Schuld trifft.
An dieser Stelle auch noch einmal ein herzliches Dankeschön an alle Entwickler und Diejenigen, die daran teilhaben und das Projekt unterstützen. Eine tolle Sache die meinen allergrößten Respekt verdient !
Aber deswegen war es mir auch wichtig hier in diesem Beitrag noch einmal den eigentlichen Fehler zu posten, damit auch andere wie ich, die einfach nur die SuFi benutzen eine Spur erhalten.

Der Unterschied zu damals ist, dass ich heute (Familie, Beruf, Haus, ...) bei weitem nicht mehr so viel Zeit habe um mich mit den Themen zu beschäftigen und vielleicht auch mal ein paar blöde Fragen mehr poste und vielleicht mehr Hilfe benötige, aber deswegen werde ich Debian nicht den Rücken kehren.

... und ja, ich werde die "Mount-Units" ausprobieren, da wie du schon geschrieben hast, das wohl die beste Lösung zu sein scheint, zumindest meine Interpretation.
Wenn ich mich irre, dann nur zu
Ich bin offen !

[TomL]

... und ja, eine andere Distribution wäre für mich vielleicht besser geeignet die einem mehr abnimmt und mir das Leben einfacher macht, aber:

Das Problem ist bei allen Distributionen das gleiche, wenn sie systemd verwenden oder theoretisch vielleicht ein anderes Init-System einsetzen, welches ebenfalls soviel wie möglich gleichzeitig zu starten versucht. Dann muss der Anwender selber sicherstellen, dass seine von ihm nachträglich hinzugefügten Abhängigkeiten erfüllt sind. Ein Boot-System weiss erst Mal nichts von Deinen NFS-Laufwerken, es muss erst mal auch dann booten, wenn die gar nicht vorhanden sind. Und wenn du diese dem Init-System 'unbekannten' Laufwerke hinzufügst, muss Du dem Init-System auch mitteilen, wann es die bearbeiten darf.....ansonsten versucht es das einfach zum frühesten Zeitpunkt, den es selber bestimmt.... und genau da hakt es dann mit dem Netzwerk.

Ein weitere imho auch sehr einfache Alternative wäre für Dich ein einfaches Mount-Script. Da kannst Du alle Mounts ähnlich der fstab nacheinander eintragen. Aber auch dafür braucht es dann eine Systemd-Unit, um das Script zum passenden Zeitpunkt zu starten.

[rendegast]

#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/ user,noauto,timeo=14,soft,intr 0 0

Bei Deinem letzten Eintrag

192.168.1.4:/srv/video/ /mnt/yaVDR2Video/ user,noauto,timeo=14,soft,intr 0 0

fehlt 'nfs'.
Wohl die Ursache des Problems.




Die Einträge in meiner fstab erzeugen

/var/run/systemd/generator/local-fs.target.requires/mnt-yaVDR2Video.mount

/var/run/systemd/generator/mnt-Netbook.mount
/var/run/systemd/generator/mnt-T410.mount
/var/run/systemd/generator/mnt-yaVDR1ShareVDR.mount
/var/run/systemd/generator/mnt-yaVDR1Video.mount
/var/run/systemd/generator/mnt-yaVDR2.mount
/var/run/systemd/generator/mnt-yaVDR2Video.mount

also ein lokaler Mount, der dann ja nicht vollzogen werden kann.
Zudem in der erzeugten Unit
Type=user,noauto,timeo=14,soft,intr
Options=0
also invalide.

wish-bug: systemd resp. dessen Mount-generator prüft die Validität der Einträge und macht Meldung statt Bockmist.
'crontab' kann das ja auch.

[Celica]

OK, der fehlende Eintrag bzgl. "nfs" war ein Kopierfehler durch mich.

Habe schon wieder viel gelernt , danke dafür.
Mir war ja halbwegs (ich betone!) klar wie Systemd tickt, aber realisieren wird MANN das immer erst dann, wenn die Konfrontation vor der Tür steht.

Ich würde dann mal versuchen das mit einer Mount-Unit zu testen.

Aber definitiv waren es die NFS-Einträge in meiner "fstab" die den Systemstart via Systemd vereitelt haben.
Das Upgrade (so wie ich auch schon geschrieben hatte) ist super durchgelaufen und ich war nur nicht in der Lage zu erkennen woran es gelegen hat.
Mit dem Wissen von heute wäre ich wohl früher darauf gekommen.

Hatte aber auch etwas gutes: Ich habe meine ganzen Altlasten (habe KDE und GNOME zwischenzeitlich getestet) entsorgt. Der Rechner wird sicherlich nicht mehr ganz so zugemüllt sein.

[Celica]

Ich muss mich korrigieren: Die fehlende Option/Argument "nfs" war kein Kopierfehler, sondern ein echter Fehler den ich vorher auch schon in meiner "fstab" hatte.
Ist nie aufgefallen, da ich das Laufwerk so nie benutzt habe.

Ich habe nun die Option/Argument eingetragen und alle Laufwerke frei gechaltet.

Was soll ich sagen: Der Rechner bootet ohne zu murren.

Ich würde jetzt probieren die restliche Konfiguration vorzunehmen um zu schaun ob es grundsätzlich funktioniert.

Ich habe aber hier gelernt, dass mit Mount-Units das eigentlich die besser Wahl ist und wahrscheinlich auch nur Glück ist, wenn es mit meinen Einträgen in der "fstab" funktioniert.

Kann das aber trotzdem so sein, dass es reibungslos funktioniert ?

NACHTRAG:
Ich habe jetzt den Rechner vollständig konfiguriert für meine NFS-Laufwerke (autofs, auto.master, ...) und alles funktioniert supper. Besser wie vorher und der Rechner bleibt nicht hängen.
Eigentlich gibt es ja keinen Grund etwas zu ändern wenn alles super läuft, aber ich habe ein wenig Zweifel.
Wie kann das jetzt angehen ?
Warum läuft alles reibungslos (nicht das ich unzufrieden wäre:-)) ?
Ist das Zufall bzw. habe ich Glück ?
Ich habe ja verstanden das es sinnvoller wäre Mount-Units zu nutzen, aber ...

Was mich stutzig macht: Ich habe das Paket autofs(5) installiert und kein Ordner "autofs" war vorhanden.
Ist das Absicht ?
Ich habe einfach meinen alten Ordner mit Inhalt in die "/etc" kopiert und das funktioniert einwandfrei.

Was ist da falsch ?


Hätte ich das Problem nicht gehabt, dann wüste ich jetzt nicht, dass der Weg den ich da gerade gehe vielleicht der falsche ist. Hat auch etwas für sich !

[rendegast]

Sehen denn Deine selbsterstellten mount-Unit anders aus als die vom generator aus der fstab erzeugten?

Falls nicht, und nicht sonstige "Magie" mit diesen Units gemacht wird,
so halte ich das Vorgehen für unsinnig
(abgesehen vom Übungseffekt).
Falls mal mit sysv gebootet wird, so stehen die Mounts auch nicht zur Verfügung.

Ich habe das Paket autofs(5) installiert und kein Ordner "autofs" war vorhanden.

Sollte damit ein Ordner gemeint sein, in dem die Mounts einer *.autofs oder der entsprechenden Map landen sollen
(ich habe in in einem thread schonmal diese Bezeichnung verwendet),
dieser wird bei Nichtvorhandensein dynamisch von automount erstellt.

[Celica]

Nicht das wir uns falsch verstehen: Ich habe davon gesprochen, dass ich die Einträge direkt in die "fstab" geschrieben habe. So wie ich sie unter Wheezy eingetragen hatte.

[rendegast]

Tschuldigung, ich bezog mich da auf

Ich habe aber hier gelernt, dass mit Mount-Units das eigentlich die besser Wahl ist

systemd arbeitet so oder so mit units, seien sie nun explizit in /etc/systemd/system/ angelegt ("selbsterstellt") oder vom generator auf Basis der fstab dynamisch in /var/run/systemd/ generiert.

Vergleiche auch die dortigen dynamischen service-Units für nur als sysv-Initskript vorliegende Dienste.

[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