Jessie Upgrade mit Problemen Systemd / Sysvinit

[guennid]

Am Anfang meines Beitrages wusste ich ehrlich gesagt noch gar nicht so Recht wo der Schuh drückt.

Kann ich sehr gut nachvollziehen. Da hilft nur: Gut überlegen: wie anfangen und wenn irgend möglich relevante Fehlermeldungen. Ansonsten wird der Thread dann leider manchmal zum gefundenen Fressen für Empörungs-Junkies.

[Celica]

Alles gut. Danke.
Werde heute alles so belassen wie es ist. Schließlich ist der Rechner ja zu benutzen.
Am letzten Tag im Jahr mache ich mir keinen Stress mehr.
Früher wäre mir das wichtig gewesen, heute liegen die Prioritäten wo anders.

Ich denke das ich in einer ruhigen Minute den Rechner neu aufsetze.

Ich wünsche hier allen einen guten Rutsch ins neue Jahr.

[Taomon]

Zeig mal das

Code: Alles auswählen

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

Habe ich bei mir nicht drauf und steht auch (deprecated) bei den Paketen in deiner Ausgabe.


Gruß Taomon

[Celica]

Hallo,

ich wünsche allen ein frohes neues Jahr.

Bevor ich das System neu aufsetze, wollte ich noch der Aufforderung aus dem letzten Beitrag nachkommen.

Code: Alles auswählen

root@debian:~# apt --dry-run purge libsystemd-daemon0:amd64 libsystemd-login0:amd64 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  libsystemd-daemon0* libsystemd-login0*
0 aktualisiert, 0 neu installiert, 2 zu entfernen und 1 nicht aktualisiert.
Purg libsystemd-daemon0 [215-17+deb8u5]
Purg libsystemd-login0 [215-17+deb8u5]

Hat aber keine Auswirkung auf mein eigentliches Problem bzgl. "systemd".

Trotzdem herzlichen Dank.

[guennid]

Mit --dry-run simulierst du lediglich eine Operation, ohne sie auszuführen. Auf gut deutsch also "Trockenübung"

Vermute, das war nicht bekannt, wenn doch, vergiss meinen Hinweis.

Der Parameter ist ziemlich überflüssig, da apt beim Removen immer nachfragt und Abbruchoption bietet. Aber na ja, an Parkinson-Leidende mögen das anders sehen.

[edit] Kommafehler

[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.