Jessie Upgrade mit Problemen Systemd / Sysvinit

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
TomL

Re: Jessie Upgrade mit Problemen Systemd / Sysvinit

Beitrag von TomL » 10.01.2017 14:30:57

scientific hat geschrieben: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

Re: Jessie Upgrade mit Problemen Systemd / Sysvinit

Beitrag von TomL » 10.01.2017 15:02:24

rendegast hat geschrieben: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
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Jessie Upgrade mit Problemen Systemd / Sysvinit

Beitrag von rendegast » 10.01.2017 15:25:33

TomL hat geschrieben: 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 ;)
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

TomL

Re: Jessie Upgrade mit Problemen Systemd / Sysvinit

Beitrag von TomL » 10.01.2017 15:36:53

rendegast hat geschrieben: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.
rendegast hat geschrieben:

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
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Jessie Upgrade mit Problemen Systemd / Sysvinit

Beitrag von scientific » 10.01.2017 16:13:18

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 :D
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
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
Celica
Beiträge: 2145
Registriert: 16.08.2003 13:37:15
Wohnort: Schleswig Holstein

Re: Jessie Upgrade mit Problemen Systemd / Sysvinit

Beitrag von Celica » 10.01.2017 22:02:36

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.
Danke !

Ciao

Celica

Antworten