Hallo zusammen
Ich muss unbedingt SystemD loswerden, kennt jemand eine Liste mit
Distribution die kein SystemD verwenden? Oder soll ich bei Debian
Bleiben und versuchen SystemD zu ersetzen? Und welche Init Systeme könnt
ihr empfehlen?
Erstmal zu was mir diesmal passiert ist. Ich Update all meine Systeme
und LXC Container, also Webserver, Mailserver, und KVM Host. Danach
starteten Postfix, Dovecot, OpenDKIM, und ne von Roundcube benötigte
Datenbank nichtmehr. Hat sich herausgestellt, dass dass beim Update
einerseits neue fehlerhafte .service files generiert und die alten
ersetzt wurden, und andererseits die Services unsauber gekillt wurden,
wodurch die Pidfiles nicht gelöscht wurden, was dann wieder zu Problemen
geführt hat. Ich vermute, das SystemD nach und nach versucht Configfiles
und ältere Initscripts zu ersetzen.
Zieht euch nur mal das generierte /lib/systemd/system/postfix.service
file rein, und das war noch harmlos:
1
[Unit]
2
Description=Postfix Mail Transport Agent
3
After=network.target
4
Conflicts=sendmail.service exim4.service
5
ConditionPathExists=/etc/postfix/main.cf
6
7
[Service]
8
Type=oneshot
9
RemainAfterExit=yes
10
ExecStart=/bin/true
11
ExecReload=/bin/true
12
13
[Install]
ExecStart=/bin/true! WTF! So wird postfix sicher nicht gestarted!
Aber es kommt noch besser, schaut euch das neue
/lib/systemd/system/opendkim.service an:
1
# Automatically Generated by opendkim systemd service file generator.
2
# To change the editable parameters, edit /etc/default/opendkim and then do
3
# systemctl restart opendkim.
4
5
# If you are using OpenDKIM with SQL datasets it might be necessary to start
6
# OpenDKIM after the database servers. For example, if using both MariaDB and
7
# PostgreSQL, edit /etc/default/opendkim to add the needed definitions to
8
# EXTRAAFTER. If used, mariadb.service and postgresql.service would have to be
9
# added.
10
11
[Unit]
12
Description=OpenDKIM DomainKeys Identified Mail (DKIM) Milter
Das File bei chown gibt's nicht, bei mkdir fehlt das Verzeichnis, Group
und PIDFile sind nicht gesetzt, und beim parameter -P wurde das pidfile
auch weggelassen! WTF! (Im Anhang ist noch das
/lib/opendkim/opendkim.service.generate).
Mein entschluss steht fest, ich muss diesen SystemD Tumor, der mein
System versäucht und sich langsam alle Aufgaben unter den Nagel reisst,
für die ein Init System nicht zuständig ist, loswerden. Was war das
letzte grosse Ding, ein systemd Wrapper für mount? Und davor das Killen
von Prozessen beim beenden einer Session? Und davor... Es gibt ganzte
Listen davon im Internet! Wieso springen alle auf den SystemD zug auf,
merkt den keiner was da abgeht? Wir steuern direckt auf einen SystemD
LockIn mit SystemD Apokalypse zu! Ist es schon zu spät? Selbst
Canonicals Upstart erscheint mir im vergleich zu SystemD mittlerweile
ganz sympathisch.
Hab auch noch einen systemd-Rant: Wenn man ntpdate installiert hat,
startet der systemd-ntp-Dienst nicht. Keine Ahnung warum, es gibt IMO
keinen sinnvollen Grund für so einen Schwachsinn (muss ja Absicht sein)
und auch keine Meldung im Log. Früher konnte man halt ntpdate nicht
aufrufen, wenn der ntpd schon lief.
Wenn man auf genaue Zeit angewiesen ist, kann einen das schon ziemlich
beissen...
Ich habe inzwischen den Verdacht, dass der Poettering auf der
Gehaltsliste von MS steht, um Linux langfristig zu ruinieren.
Auf meinem RPi (Arch Linux) hab ich auch Probleme damit. Nach einem
Update von systemd 217 auf irgend eine neuere Version Starten meine
Dienste auch nicht mehr ohne weiteres, und über ssh komm ich dann auch
nicht mehr rauf...
Leider bin ich zu spät in die Nutzung von Linux eingestiegen, und kann
deshalb keinen brauchbaren Vergleich von systemd zu den vorherigen
init-systemen zu ziehen. Aber "gut" finde ich systemd nicht.
Ich werde mir wohl mal OpenRC ansehen. OpenRC kommt von den
Gentoo-Entwicklern.
https://wiki.gentoo.org/wiki/Project:OpenRChttps://wiki.manjaro.org/index.php?title=OpenRC,_an_alternative_to_systemd
1
OpenRC, an alternative to systemd
2
3
OpenRC is a dependency based init system maintained by the Gentoo
4
developers, that works with the system provided init program, normally
5
sysvinit. It is not a replacement for sysvinit.
6
7
It is an alternative to systemd for users that like more control over their
8
system, and do not want all the features that systemd provides and
In der Arbeit hab ich Debian mit SystemD, bin nicht zufrieden damit.
Zuhause hab ich Gentoo, ohne SystemD. Zufrieden damit. OpenRC kannst du
da beispielsweise verwenden.
Daniel A. schrieb:> Hallo zusammen>> Ich muss unbedingt SystemD loswerden, kennt jemand eine Liste mit> Distribution die kein SystemD verwenden? Oder soll ich bei Debian> Bleiben und versuchen SystemD zu ersetzen? Und welche Init Systeme könnt> ihr empfehlen?
Windows 10 mit Linux-Subsystem
http://heise.de/-3163994.html
</troll> :)
> Nimm FreeBSD.
Das ist ja kein Linux-Problem an sich. Das Problem sind die
Distributionen, die meinen, dass im Kampf um den DAU-Desktop sowas
besser ist. Auf einem Server, der alle heiligen Zeiten mal bootet,
bringen die paar Sekunden Beschleunigung gar nix. Wenn man noch ein
Dell-Server-Mainboard oder einen HW-Raid-Controller drinnen hat, geht
das in dessen Startup völlig unter (Areca anyone? ;) ).
Warte nur, bis der Poettering FreeBSD als nächste Spielwiese entdeckt
:-O
Schaut euch nur mal die Harry Po(e)tter(ing) Filmreihe an - da war auch
erstmal lange Trubel, Trauer, Chaos und Zerstörung bis das Ziel erreicht
wurde ;-P ;-)
Georg A. schrieb:> Hab auch noch einen systemd-Rant: Wenn man ntpdate installiert hat,> startet der systemd-ntp-Dienst nicht. Keine Ahnung warum, es gibt IMO> keinen sinnvollen Grund für so einen Schwachsinn (muss ja Absicht sein)> und auch keine Meldung im Log. Früher konnte man halt ntpdate nicht> aufrufen, wenn der ntpd schon lief.
Debian basierendes System ? dann liegt es wahrscheinlich dadran das der
Dienst vor dem Netzwerk gestartet wird warum zur hölle das so als
default ist ka. aber das bewegen des startscrips des Netzwerk in den
Boot-runlevel löst das Problem oder alternativ als depend Netzwerk
setzen(bin nicht mehr sicher ob das bei systemd ging).
Ich kann für Debian Systemen auch OPENRC entfehlen momentan sind mir da
aber nur die Ubuntuderivate bekannt wo das langsam umgestellt wird.
Ansonsten ist da Gentoo schon ne ganze ecke weiter das neue nennt sich
Openrc-Run damit werden sie Start/Stop... Scrips vereinfacht man muss da
keine neue Wissenschaft kennen Lehrnen ums zu benutzen.
Mal nen Beispiel welches ich die Tage erstellt hatte:
> Debian basierendes System ? dann liegt es wahrscheinlich dadran das der> Dienst vor dem Netzwerk gestartet
Ubuntu. Aber mit dem Netzwerk hat das nichts zu tun. Das Paket ntpdate
installiert ja nur das Tool, um manuell die NTP-Zeit zu holen.
Georg A. schrieb:> Ubuntu. Aber mit dem Netzwerk hat das nichts zu tun. Das Paket ntpdate> installiert ja nur das Tool, um manuell die NTP-Zeit zu holen.
Es gibt Systeme, die damit bei Start einmalig die Zeit holen.
Georg A. schrieb:>> Nimm FreeBSD.>> Das ist ja kein Linux-Problem an sich. Das Problem sind die> Distributionen, die meinen, dass im Kampf um den DAU-Desktop sowas> besser ist. Auf einem Server, der alle heiligen Zeiten mal bootet,> bringen die paar Sekunden Beschleunigung gar nix. Wenn man noch ein> Dell-Server-Mainboard oder einen HW-Raid-Controller drinnen hat, geht> das in dessen Startup völlig unter (Areca anyone? ;) ).>> Warte nur, bis der Poettering FreeBSD als nächste Spielwiese entdeckt> :-O
Du hast uneingeschänkt Recht mit Deiner Aussage, aber es sieht so aus
als ob alle "großen" Ditributionen Poetterring hinter her rennen weil
sie auf einem Laptop denken schnell booten zu müssen.
Mein Problem mit dem Zeuch ist das es der Kiss Regel entgegen läuft,
Software dieses Teams scheint prinzipiell nur eingeschränkt funktional
und schlecht dokumentiert zu sein. Des Weiteren gilt da scheinbar für
Eigenentwicklungen hauptsächlich die Begründung "not invented here".
Ich habs bedauert das Debian auf SystemD umgestellt hat, damit ist für
mich das letzte brauchbare Linux gestorben (Gründe der Wartung, your
mileage may vary).
Gruß,
Holm
Daniel A. schrieb:> Ich muss unbedingt SystemD loswerden, kennt jemand eine Liste mit> Distribution die kein SystemD verwenden?https://devuan.org/
Ist ein Debian-Fork ohne systemd.
Ich kann die Abneigung gegen SystemD nicht ganz nachvollziehen. Die
Probleme die ihr hier beschreibt haben alle nichts mit SystemD zu tun,
sondern mit den in eurer Distri ausgelieferten oder generierten
Konfigurationsdateien. Im Prinzip ist die Art wie SystemD Services
verwaltet den alten init-Skripten weit überlegen. Um einen Service zu
erstellen reichen 5 Zeilen Konfiguration, ich muss keine 50-100 Zeilen
Shell-Code copy&pasten, mir Gedanken machen wie ich den Service am Leben
halte, wo ich die PID-Files hinlege, wo ich stderr und stdout hinpipe.
Und ich kann mit einem simplen Befehl überprüfen ob und seit wann der
Service läuft und welche Subprozesse er gestartet hat.
@Andreas Schwarz (andreas) (Admin)
Ja, das mag sein, das ist die Schokoladenseite von SystemD die man am
Anfang sieht. Tatsächlich dachte ich früher auch mal so.
Das eigentliche Problem ist nicht das Starten und Stoppen der Services,
sondern das SystemD auch alles andere übernimmt. Das fängt irgendwo bei
systemd-udev an, geht bei consolekit und ntp weiter und hört bei
systemd-mount auf. Dadurch wird jede Anwendung die systemd-udev oder
systemd-mount benötigt, systemd benötigen. Es wird dadurch unersetzbar,
eine Art Vendor LockIn, und ein Vendor LockIn ist das schlimmste, was
OpenSource Produkten passieren kann.
Systemd entspricht auch nicht der Unix Philosophie, es tut nicht nur
eine Sache. Der init Prozess, PID1, eines Unix Systems hat genau 2
Aufgaben: Prozesse ohne Parent Process zu übernehmen und sich zu
Beenden, wenn das System ausgeschaltet wird. Das starten von Services
ist als Ergänzung noch sinnvoll, könnte aber bereits ausgelagert werden.
Andreas S. schrieb:> Ich kann die Abneigung gegen SystemD nicht ganz nachvollziehen.
Da kann ich mangels Beschäftigung mit dem Thema systemD leider nicht
mitreden. Allerdings bin ich mit SysV-Init-Scripts in der Vergangeheit
immer gut zurechtgekommen.
> Um einen Service zu> erstellen reichen 5 Zeilen Konfiguration, ich muss keine 50-100 Zeilen> Shell-Code copy&pasten, [...]
Naja, das mit den 50-100 Zeilen ist etwas übertrieben, 7 reichen auch:
1
#! /bin/sh
2
case"$1"in
3
start) start-my-daemon;;
4
stop) stop-my-daemon;;
5
restart)$0 stop;sleep 1;$0 start;;
6
*)echo"usage: $0 start|stop|restart">&2;;
7
esac
Wenn ich dann noch die restart-Option und die Usage-Zeile weglasse, bin
ich auch bei 5. :-)
Ja und nein was machst du z.b. wenn der Demon keine eigenes Pidfile
erstellt oder in mehreren Instanzen läuft dann funktionieren solche
einfachen scrips nicht wirklich gut, da reicht der 7 Zeiler nicht
bisschen komplexer ist das ganze schon, da finde ich das ehr besser wie
Openrc-run das macht da ist das ganze onboard die haben da mal besser
nach gedacht was mann braucht und das so intigiert das man das nicht
selbst erledigen muss.
K. J. schrieb:> Ja und nein was machst du z.b. wenn der Demon keine eigenes> Pidfile erstellt
Meine tun das alle :-)
Wenn man wirklich meint, ein beliebiges Programm als Demon einsetzen zu
müssen, obwohl es nicht dafür ausgelegt ist, dann hilft evtl. beim
Starten das Speichern von $! in eigener PID-Datei oder beim Stoppen noch
killall.
> oder in mehreren Instanzen läuft dann funktionieren solche> einfachen scrips nicht wirklich gut, da reicht der 7 Zeiler nicht
Klar.
> bisschen komplexer ist das ganze schon,
ACK. Ich wollte nur der pauschalen Aussage "50-100 Zeilen" etwas
entgegentreten.
Daniel A. schrieb:> Hallo zusammen>> Ich muss unbedingt SystemD loswerden, kennt jemand eine Liste mit> Distribution die kein SystemD verwenden? Oder soll ich bei Debian> Bleiben und versuchen SystemD zu ersetzen? Und welche Init Systeme könnt> ihr empfehlen?
Debian mit
Georg A. schrieb:> Hab auch noch einen systemd-Rant: Wenn man ntpdate installiert hat,> startet der systemd-ntp-Dienst nicht. Keine Ahnung warum, es gibt IMO> keinen sinnvollen Grund für so einen Schwachsinn
Naja. Ohne Wertung ob das jetzt gut oder schlecht ist: systemd bringt
seinen eigenen Zeitsynchronisierungsdienst mit. Sowohl ntpd als auch
ntpdate sind damit obsolet. Wenn es jetzt Reibung zwischen systemd und
ntpdate gibt, dann ist das nicht in erster Linie ein Problem von
systemd, sondern eines der unvollständigen Integration dieser Pakete in
der Distribution.
Ich habe auch gerade ein aktuelles Ubuntu installiert und mich ebenso
darüber geärgert, daß das (aus Gewohnheit) installierte ntpd-Paket
kommentarlos nichts tut. Erwartet hätte ich eine Meldung des
Paket-Managements, daß ntpd jetzt obsolet ist, weil seine Funktion
bereits in systemd enthalten ist.
Auch sonst sind mir eine Menge Merkwürdigkeiten rund um systemd
aufgefallen, etwa die perverse Zahl an cgroup Mounts. Und die
<nachzähl> 8 neuen daemon-Prozesse aus dem systemd-Umfeld. Andererseits
funktioniert erstmal alles. Es ist also erst mal nur anders, nicht
kaputt. Ein großer Unterschied.
Und übrigens: es heißt systemd. Mit kleinem s und kleinem d.
Insbesondere das kleine d ist traditionell (und ist das nicht ein Thread
über Traditionen und die Gefahren beim Abweichen von ihnen?). Das kleine
"d" steht nämlich für daemon.
Daniel A. schrieb:> Das eigentliche Problem ist nicht das Starten und Stoppen der Services,> sondern das SystemD auch alles andere übernimmt. Das fängt irgendwo bei> systemd-udev an, geht bei consolekit und ntp weiter und hört bei> systemd-mount auf.
Ich sehe einen ganz großen Vorteil von systemd darin, daß endlich die
Abhängigkeiten der Dienste und Funktionen untereinander sauber
modelliert werden können. Und wenn man das zuende denkt, macht es eben
wirklich Sinn da auch so Dinge wie Mountpoints mit einzubeziehen.
Beispiel:
Du hast einen Webserver, bei dem Teile der Quellverzeichnisse übers
Netzwerk (z.B. NFS) gemounted werden.
Du musst also erst warten bis eine Netzwerkverbindung da ist, dann den
NFS-Mountpoint mounten und wenn das alles erfolgreich war dann erst den
Webserver starten.
Bei SysV-Init konntest Du zwar die Startreihenfolge einstellen. Aber
wenn ein Dienst über einen einfachen Timeout hinaus brauchte, startete
der Rest und schlug dann fehl.
Bei systemd startet der Rest auch sauber, wenn z.B. die
Netzwerkverbindung erst nach ner halben Stunde hergestellt wird. Oder
der NFS-Server erst später wieder erreichbar ist.
Axel S. schrieb:> Naja. Ohne Wertung ob das jetzt gut oder schlecht ist: systemd bringt> seinen eigenen Zeitsynchronisierungsdienst mit. Sowohl ntpd als auch> ntpdate sind damit obsolet.
Exakt, warum tut das Teil Sachen, für die es schlicht nicht zuständig
ist? Ntp läuft auf dem Server, nicht Client, so war das schon immer!
> Exakt, warum tut das Teil Sachen, für die es schlicht nicht zuständig> ist? Ntp läuft auf dem Server, nicht Client, so war das schon immer!
Der ntpd (oder wie auch immer er sich nennt) läuft natürlich auch auf
dem Client, damit er die Zeit kontinuierlich nachführen kann. An den
könnte man sich auch wieder verbinden (falls erlaubt), aber zu tiefe
NTP-Hierarchien helfen natürlich auch nicht in der Genauigkeit...
"Früher" lief häufig zuerst ntpdate, um die korrekte Zeit schnell zu
setzen, danach ntpd, um das langsam nachzuführen. Das verhindert, dass
der ntpd nach dem Booten noch länger die Differenzzeit rumziehen muss.
Gerd E. schrieb:> Daniel A. schrieb:>> Das eigentliche Problem ist nicht das Starten und Stoppen der Services,>> sondern das SystemD auch alles andere übernimmt. Das fängt irgendwo bei>> systemd-udev an, geht bei consolekit und ntp weiter und hört bei>> systemd-mount auf.>> Ich sehe einen ganz großen Vorteil von systemd darin, daß endlich die> Abhängigkeiten der Dienste und Funktionen untereinander sauber> modelliert werden können. Und wenn man das zuende denkt, macht es eben> wirklich Sinn da auch so Dinge wie Mountpoints mit einzubeziehen.>> Beispiel:>> Du hast einen Webserver, bei dem Teile der Quellverzeichnisse übers> Netzwerk (z.B. NFS) gemounted werden.>> Du musst also erst warten bis eine Netzwerkverbindung da ist, dann den> NFS-Mountpoint mounten und wenn das alles erfolgreich war dann erst den> Webserver starten.>> Bei SysV-Init konntest Du zwar die Startreihenfolge einstellen. Aber> wenn ein Dienst über einen einfachen Timeout hinaus brauchte, startete> der Rest und schlug dann fehl.>> Bei systemd startet der Rest auch sauber, wenn z.B. die> Netzwerkverbindung erst nach ner halben Stunde hergestellt wird. Oder> der NFS-Server erst später wieder erreichbar ist.
Huckauf.
Bei einem diskless System ist es sinnvoll /usr usw. "hart" zu mounten
und anzuhalten wenn der Server nicht verfügbar ist.
Bei einem System das das nicht braucht ist es ein Administrator Fault
das so zu tun und das wußten die Admins schon Jahre vorher...
..erkläre mir mal wie ich bei einer gecrashten und von der CD (oder
flash) gebooteten Maschine die Syslogs lese um heraus zu finden was
vorgefallen war..
Bisher ging das mit more oder less...
Anmerkung mich interessiert dann der Inhalt einer beim crash zum
Schreiben offen gewesenen Datei mit Binärbäumen...
Gruß,
Holm
Lukas S. schrieb:> Daniel A. schrieb:>> Hallo zusammen>>>> Ich muss unbedingt SystemD loswerden, kennt jemand eine Liste mit>> Distribution die kein SystemD verwenden? Oder soll ich bei Debian>> Bleiben und versuchen SystemD zu ersetzen? Und welche Init Systeme könnt>> ihr empfehlen?> Debian mit> sudo apt-get install sysvinit
Ich habe das gerade in meinem Debian Test LXC Container ausprobiert, vor
dem apt-get update gab es soein packet noch, danach nichtmehr. Muss erst
gerade vor kurzem entfernt worden sein.
Ich habe das deshalb mal zum Spass versucht OpenRC darauf zu
installieren ausprobiert, natürlich wird man dabei das ganze systemd
nicht los, und die Installation ist mir nicht gelungen. Dann habe ich
versucht systemd zu deinstallieren, was es mich auch nicht machen lassen
wollte. Und das Debian war ein relativ frisches debootstrap.
-----------------
Meine kurzfristigen Erfahrungen mit devuan als LXC Kontainer sind sehr
viel angenehmer. Ein simples apt-get install openrc funktioniert
wunderbar, und es werden sehr viel weniger unnötige Dienste gestartet.
Soweit funktioniert alles einwandfrei damit. Ich habe dadurch sogar noch
Probleme in meinem Netzwerk gefunden! Wenn in Linux (debian) oder
FreeBSD (pfSense) bei einem virtio Netzwerkinterface checksum hardware
offloading nicht abgeschaltet wird, werden fehlerhafte Checksummen
generiert. Bei pfSense habe ich das früher schon mal bemerkt, bei den
debian LXC Containern war es mir bisher aber nie aufgefallen. Als ich
mit tcpdump nachgesehen habe hat mein lokaler debian dns server im LXC
Container doch tatsächlich falsche checksums in den DHCP replays
generiert, und die anderen debian Container haben es einfach Ignoriert,
und die Packete akzeptiert! Nachdem ich das CHecksum offloading bei
allen Containern ausgeschaltet hatte, hat dann auch devuan die DHCP
Replays wieder akzeptiert, weil die checksumme wieder stimmte. Da frage
ich mich doch, sind das die Debian Leute oder die systemd leute, die
diese Checksummenüberprüfung statt das offloading ausgeschalten haben?
Auf jeden fall glaube ich, das mir zukünftige Updates diesmal nicht mehr
so häufig alles zerstören, was ich eingerichtet habe.
Gerd E. schrieb:> Und wenn man das zuende denkt, macht es eben> wirklich Sinn da auch so Dinge wie Mountpoints mit einzubeziehen.>> Beispiel:>> Du hast einen Webserver, bei dem Teile der Quellverzeichnisse übers> Netzwerk (z.B. NFS) gemounted werden.>> Du musst also erst warten bis eine Netzwerkverbindung da ist, dann den> NFS-Mountpoint mounten und wenn das alles erfolgreich war dann erst den> Webserver starten.
Das sehe ich anders. Es gibt etablierte, bestehende und gute Dienste,
die NFS Mounten können, z.B. autofs. Aus Sicht eines service init
systems wäre das eine simple Abhängigkeit des Webservers zu diesem, das
Init system sollte sich nicht selbst um sowas kümmern. Das geht mit so
ziemlich jedem init system so. Ausserdem muss gerade bei Webservern das
DocumentRoot nicht unbedingt von Anfang an da sein.
Guido B. schrieb:> Axel S. schrieb:>> Naja. Ohne Wertung ob das jetzt gut oder schlecht ist: systemd bringt>> seinen eigenen Zeitsynchronisierungsdienst mit. Sowohl ntpd als auch>> ntpdate sind damit obsolet.>> Exakt, warum tut das Teil Sachen, für die es schlicht nicht zuständig> ist? Ntp läuft auf dem Server, nicht Client, so war das schon immer!
Du beliebst zu scherzen! ntpd muß auf jedem System laufen, das die
korrekte Uhrzeit haben soll. Denn es ist nicht nur Server, sondern vor
allem (vermutlich in 99% aller Installationen) Client.
Was ich systemd (respektive Poettering und seinen Jüngern) vorwerfe, ist
daß sie Dinge in systemd integrieren, die vorher schon hervorragend
außerhalb systemd funktioniert haben. ntpd ist da das passende Beispiel.
systemd-timesyncd löst kein Problem, das ntpd nicht auch gelöst hätte.
Auf der gleichen Welle reitet übrigens auch dbus. Ich habe gerade den
accounts-daemon (Paket accountsservice) von meinem Ubuntu-System
geworfen, was gar nicht so einfach war, weil Canonical das Drecksteil
zusammen mit wirklich wichtigen Sachen wie cpio und usbutils in das
virtuelle ubuntu-standard Paket getan hat. Warum ich einen permanent
laufenden daemon Prozeß brauche, damit (laut Doku) adduser & Consorten
funktionieren, wissen wohl nur die Spacken von freedesktop.org. Über
Dekaden waren getpwnam() und getpwuid() gut genug, aber jetzt braucht
man auf einmal dbus und einen eigenen Daemon dafür? AARGH! GEHT STERBEN!
Daniel A. schrieb:>> Du musst also erst warten bis eine Netzwerkverbindung da ist, dann den>> NFS-Mountpoint mounten und wenn das alles erfolgreich war dann erst den>> Webserver starten.>> Das sehe ich anders. Es gibt etablierte, bestehende und gute Dienste,> die NFS Mounten können, z.B. autofs. Aus Sicht eines service init> systems wäre das eine simple Abhängigkeit des Webservers zu diesem, das> Init system sollte sich nicht selbst um sowas kümmern. Das geht mit so> ziemlich jedem init system so. Ausserdem muss gerade bei Webservern das> DocumentRoot nicht unbedingt von Anfang an da sein.
Sowas von ACK. Überhaupt ist ein Webserver, dessen Document-Root auf
einem NFS-Share liegt, eine Fehlkonstruktion. Teilbäume des Doc-Root im
NFS, alles OK. Aber das Doc-Root selber gehört doch bitte auf die
Maschine auf der der Webserver läuft. Im Zweifel packt man den Webserver
halt auf die Maschine, die das NFS-Share exportiert. Ist doch am Ende eh
Wurscht, wo der Prozeß läuft. Der muß nur Daten vom Massenspeicher auf
das Netzwerkinterface kopieren können. Da ist das doch besonders
kontraproduktiv, wenn der Massenspeicher auch wieder über das Netzwerk
(womöglich gar das gleiche Interface) angebunden ist.
Wahrscheinlich besteht die Zielgruppe dafür aus den Knilchen, die alles
diskless machen und bei denen der NFS-Server eine zugenagelte Appliance
ist, auf der man keinen eigenen Webserver laufen lassen kann.
Axel S. schrieb:> Daniel A. schrieb:>>> Du musst also erst warten bis eine Netzwerkverbindung da ist, dann den>>> NFS-Mountpoint mounten und wenn das alles erfolgreich war dann erst den>>> Webserver starten.>>>> Das sehe ich anders. Es gibt etablierte, bestehende und gute Dienste,>> die NFS Mounten können, z.B. autofs. Aus Sicht eines service init>> systems wäre das eine simple Abhängigkeit des Webservers zu diesem, das>> Init system sollte sich nicht selbst um sowas kümmern.
Zum gesamten autofs?
Das muss alle möglichen Verzeichnisse von allen möglichen Servern
mounten. Der Webserver aus meinem Beispiel braucht genau ein
Verzeichnis, was die anderen machen ist ihm egal. Ich muss also ein
speziellen Mountpoint als Abhängigkeit für einen Dienst festlegen
können.
Ich denke da ist es schon die beste Lösung den Mountpoint selbst durch
das Initsystem verwalten zu lassen.
> Sowas von ACK. Überhaupt ist ein Webserver, dessen Document-Root auf> einem NFS-Share liegt, eine Fehlkonstruktion. Teilbäume des Doc-Root im> NFS, alles OK. Aber das Doc-Root selber gehört doch bitte auf die> Maschine auf der der Webserver läuft. Im Zweifel packt man den Webserver> halt auf die Maschine, die das NFS-Share exportiert.
Bei der Maschine die ich hier als Beispiel genommen habe geht es um
Sicherheit, Performance ist egal. Das DocRoot ist readonly per NFS
gemountet. Es darf vom Webserver aus keine Möglichkeit geben dort Daten
zu ändern, auch nicht bei einer kompletten Kompromitierung des
Webserverprozesses und einer Rechteerweiterung auf root auf diesem
Rechner.
> Wahrscheinlich besteht die Zielgruppe dafür aus den Knilchen
Wenn Du sachlich bleibst, nimmt man Deine Argumente ernster.
Axel S. schrieb:> Im Zweifel packt man den Webserver> halt auf die Maschine, die das NFS-Share exportiert.
Bei einem reinen NAS ist das schwierig.
> Der muß nur Daten vom Massenspeicher auf> das Netzwerkinterface kopieren können.
Das kommt bei Webservern zwar hin und wieder noch vor, aber deren
Hauptaufgabe sind heute aktive Seiten.
Daniel A. schrieb:> Hallo zusammen>> Ich muss unbedingt SystemD loswerden, kennt jemand eine Liste mit> Distribution die kein SystemD verwenden? Oder soll ich bei Debian> Bleiben und versuchen SystemD zu ersetzen? Und welche Init Systeme könnt> ihr empfehlen?> Mein entschluss steht fest, ich muss diesen SystemD Tumor, der mein> System versäucht und sich langsam alle Aufgaben unter den Nagel reisst,> für die ein Init System nicht zuständig ist, loswerden.
<werbung>
runit wäre eine Option. Distribution: Void Linux, Rolling Release,
LibreSSL statt OpenSSL und bei Bedarf musl statt glibc.
Die Paketverwaltung unterstützt Binär- und Quelltextpakete wie bei BSDs
üblich, mehrere Kernel, lokale und remote Repositories etc. pp
Habe die seit >1 Jahr auf ein paar Rechnern und einem Laptop als
Hauptsystem im Einsatz.
Probleme bislang: keine, im Gegensatz zu anderen rollenden
Distributionen, die hier nur noch zum Testen dienen.
Nachteile: Weniger Binärpakete als bei anderen Distros.
Vor- oder Nachteil, je nach Sichtweise: Etwas mehr Handarbeit nötig.
http://www.voidlinux.eu/
</werbung>
Muss doch nochmal hier posten. Nachdem der Upgrade von jessie zu stretch
ein einziges Verwurschteln mit systemd verursacht hat, habe ich jetzt
auch Devuan installiert.
Funktioniert alles bestens. Vielen Dank für diesen Tipp! Lässt sich auch
wunderbar mit webmin verwalten.
Die Fehlermeldungen von systemctl waren aber sowas von nicht hilfreich,
das ich nach einer Nacht am Server entnervt aufgegeben hatte.
Matthias S. schrieb:> Muss doch nochmal hier posten. Nachdem der Upgrade von jessie zu stretch> ein einziges Verwurschteln mit systemd verursacht hat, habe ich jetzt> auch Devuan installiert.> Funktioniert alles bestens. Vielen Dank für diesen Tipp! Lässt sich auch> wunderbar mit webmin verwalten.
Das ist noch immer nicht die Schuld von systemd, sondern der
Distribution.
mh schrieb:> Das ist noch immer nicht die Schuld von systemd
Doch, das ist die Schuld von systemd. Hast du dir mal die Dokumentation
angesehen? Das kann ein normaler Mensch gar nicht nachvollziehen, da sie
schon mittendrin anfangen. Wofür sind die .targets? Was basiert auf
welchen Voraussetzungen? Was sollen nutzlose Hinweise wie 'To find out
about errors, use 'journalctl - xb', was nun gar nichts aussagt. Warum
lande ich auf dauernd auf dem emergency.target?
Ich hatte jedenfalls nach dieser Nacht die Schnauze voll - hey, ich
wollte wg. auslaufendem Support für jessie einfach nur auf stretch
upgraden. Mehr nicht.
Ich hatte dann sogar noch alle roten Zeilen beim o.a. Journal beseitigt,
trotzdem immer emergency.target.
Danke für nichts, systemd.
Vielen Dank an Devuan
Wer nutzt denn noch debian? Das ist ne Distrovorlage um ne eigene Distro
zu bauen, das war früher mal brauchbar heute leider ein schlecht
gepflegter Müllhaufen, is' so.
Nimm X|l|k|u|buntu, das funktioniert, auch systemd und auch system
updates.
Update hier schon seit 16.x auf dem selben System, aktuell 20.04.
Matthias S. schrieb:> mh schrieb:>> Das ist noch immer nicht die Schuld von systemd>> Doch, das ist die Schuld von systemd. Hast du dir mal die Dokumentation> angesehen? Das kann ein normaler Mensch gar nicht nachvollziehen, da sie> schon mittendrin anfangen. Wofür sind die .targets? Was basiert auf> welchen Voraussetzungen? Was sollen nutzlose Hinweise wie 'To find out> about errors, use 'journalctl - xb', was nun gar nichts aussagt. Warum> lande ich auf dauernd auf dem emergency.target?> Ich hatte jedenfalls nach dieser Nacht die Schnauze voll - hey, ich> wollte wg. auslaufendem Support für jessie einfach nur auf stretch> upgraden. Mehr nicht.
Dann kritisiere die Dokumentation, das ist berechtigt. In deinem ersten
Beitrag hast du allerdings beschrieben, dass das Update der Distro alles
"Verwurschtelt" hat. Das sind zwei ziemlich unterschiedliche Dinge...
Leider verwenden inzwischen auch SuSE (SLES) und CentOS/RedHat systemd
:-(
Die Startzeiten sind auf Servern ja eher Nebensache, da sie idR
durchlaufen sollen, daher gab es eigentlich keinen dringenden Grund.
Als reinen Init-Ersatz fände ich systemd garnicht schlecht, man gewöhnt
sich dran und immer wieder die gleiche Mimik in den Startskripten zu
implementieren ist wahrlich nicht sinnvoll. Die Behandlung von
Abhängigkeiten ist auch ein nettes Feature.
Hatte bis jetzt auf SLES und CentOS keine Probleme mit systemd, nur das
Logging (journalctl blah) finde ich nervig. Beim Debugging rufe ich dann
meistens die Sachen doch wieder manuell auf. Sie hätten es besser beim
Starten von Diensten belassen und den Rest auslagern sollen.
Sorry aber der muss sein: das Projekt heißt "systemd". Nicht "SystemD".
Wenn Leute sich über "liNuX" beschweren würden, würdet ihr die auch
nicht ernst nehmen. ;)
Dazu kommt wie schon gesagt wurde, dass die hier genannten Probleme nix
mit systemd zu tun haben, sondern mit gammligen Konfigurationsdateien.
Da kann systemd erstmal nix dafür.
Dann muss ich zum generellen Verlauf sagen: SysVinit gab es ewig lang
und es war nie gut. Diese Start-Stop-Skripte sind ein Desaster, und
mit den Units vom systemd nicht zu vergleichen. Seit systemd gibt es
endlich ein Init-System, was auf quasi allen Distributionen gleich
funktioniert, was vernünftiges Dependency-Management hat, Services
zuverlässig wieder stoppen kann, sodass die gestarteten Prozesse danach
auch tatsächlich weg sind (dank cgroups, nein, das bietet die
Shellskript-Hölle nie, egal wie man es macht), und als Bonus bootet es
noch in endlicher Zeit.
Das Projekt hat seine Probleme, davon kann ich ein Lied singen. Aber
seinen Vorgängern weine ich ganz sicher keine Träne nach.
Sven B. schrieb:> Seit systemd gibt es endlich ein Init-System, was auf quasi allen> Distributionen gleich funktioniert,
Allerdings halt nur unter Linux, weil es absichtlich so gemacht ist,
dass es auf anderen unixoiden Systemen nicht funktioniert.
> was vernünftiges Dependency-Management hat, Services zuverlässig wieder> stoppen kann, sodass die gestarteten Prozesse danach auch tatsächlich weg sind> (dank cgroups, nein, das bietet die Shellskript-Hölle nie, egal wie man es> macht), und als Bonus bootet es noch in endlicher Zeit.
Wie Markus schon schrieb: Wenn es sich denn darauf beschränken würde,
nur das zu tun, wäre das ja noch ok, aber das tut es eben nicht.
Wenn man sich https://de.wikipedia.org/wiki/Systemd#Kritik mal
durchliest, bekommt man auch den Eindruck, dass die Entwickler der
Aufgabe nicht wirklich gewachsen sind.
> Das Projekt hat seine Probleme, davon kann ich ein Lied singen.
Ich hatte zwar noch nicht allzu oft Probleme damit, aber wenn ich eins
hatte, war das meist ziemlich dubios und schwer zu erkennen, wie man es
beheben könnte. Das letzte, das ich hatte, war, dass plötzlich kein
Name-Lookup mehr funktionieren wollte. Warum hat systemd da überhaupt
seine Finger drin?
> Aber seinen Vorgängern weine ich ganz sicher keine Träne nach.
Nur weil die nicht ideal waren, heißt das nicht, dass systemd gut wäre.
Markus M. schrieb:> Die Startzeiten sind auf Servern ja eher Nebensache, da sie idR> durchlaufen sollen, daher gab es eigentlich keinen dringenden Grund.
Bei vielen Servern spielt die Verfügbarkeit durchaus eine Rolle. Und
wenn die Büchse schon ewig mit dem POST, dem Initialisierung des
Raidcontrollers und anderem Gedöns vertändelt, freuen die Nutzer des
Systems und ich uns sehr darüber, wenn dann nicht noch auf ein rein
serielles Initsystem gewartet werden muß.
> Als reinen Init-Ersatz fände ich systemd garnicht schlecht, man gewöhnt> sich dran und immer wieder die gleiche Mimik in den Startskripten zu> implementieren ist wahrlich nicht sinnvoll. Die Behandlung von> Abhängigkeiten ist auch ein nettes Feature.>> Hatte bis jetzt auf SLES und CentOS keine Probleme mit systemd, nur das> Logging (journalctl blah) finde ich nervig.
Man kann das so konfigurieren, daß journald die Logmessages auch zum
Syslog weiterleitet. Dazu gibt es in der /etc/systemd/journald.conf die
Option "ForwardToSyslog", wenn ich mich recht entsinne.
Übrigens: wer mehrere Maschinen betreibt und es ein bisschen
komfortabler haben möchte, loggt vielleicht lieber in eine zentrale
Instanz wie etwa Elasticsearch, InfluxDB, oder Prometheus. (Graylog
haben wir uns angesehen, ist aber aufgrund seiner Bugs und mangelnder
Flexibilität wieder rausgeflogen.)
> Beim Debugging rufe ich dann> meistens die Sachen doch wieder manuell auf. Sie hätten es besser beim> Starten von Diensten belassen und den Rest auslagern sollen.
Haben sie ja, und das, wohin sie es ausgelagert haben, heißt journald.
Rolf M. schrieb:> Sven B. schrieb:>> Seit systemd gibt es endlich ein Init-System, was auf quasi allen>> Distributionen gleich funktioniert,>> Allerdings halt nur unter Linux, weil es absichtlich so gemacht ist,> dass es auf anderen unixoiden Systemen nicht funktioniert.
Ich habe gewisse Schwierigkeiten mit der impliziten Unterstellung, daß
systemd mit Absicht darauf ausgelegt sei, auf anderen Systemen nicht zu
funktionieren. Fakt ist, daß systemd einige linuxspezifische APIs wie
Control Groups (cgroups) und Namespaces benutzt, die andere unixoide
Systeme nicht haben. Und genau das ist auch der Grund dafür, daß systemd
nicht auf andere UNIXe portiert werden kann -- zumindest solange deren
Entwickler nicht diese APIs einbauen.
Im Übrigen hat es die Entwickler anderer unixoider Systeme auch nie
geschert, ob ihre Software portabel war. SunOS/Solaris, die BSDs, sie
alle hatten und haben ein eigenes Init-System. Warum das jetzt
ausgerechnet den systemd-Entwicklern zum Vorwurf gemacht wird, ist mir
mehr als unverständlich.
Markus M. schrieb:> Die Startzeiten sind auf Servern ja eher Nebensache, da sie idR> durchlaufen sollen, daher gab es eigentlich keinen dringenden Grund.
Doch, gibt es, weil es nicht um die Bootzeit von physischen Servern
geht, sondern darum, virtuelle Maschinen zwecks computing on demand
schnellstmöglich rauf- und runterfahren zu können. Das ist cloud
computing, und damit wird richtig Geld verdient.
Musste man den Thread nach 4 Jahren wirklich nochmal aufrollen? Und
mussten die systemd-ist das einzig-wahre fanatiker den wirklich kapern?
Sven B. schrieb:> SysVinit gab es ewig lang und es war nie gut.
Ich finde es immernoch besser als systemd. Aber es gibt ja sonst auch
noch viele Alternativen, z.B. openrc, runit, etc.
> Diese Start-Stop-Skripte> sind ein Desaster, und mit den Units vom systemd nicht zu vergleichen.
Seit LSB hat man da auch eine dependency basierte Bootreihenfolge.
Länger/Komplexer müssen sie auch nicht sein. Dafür sind sie viel
Flexibler. Es gibt auch diverse Ansätze für deklarative, unit ähnliche,
init scripts, z.B. https://github.com/Daniel-Abrecht/unitscript oder
auch debians init-d-script
(https://manpages.debian.org/stretch/sysvinit-utils/init-d-script.5.en.html)
> Seit systemd gibt es endlich ein Init-System, was auf quasi allen> Distributionen gleich funktioniert,
Die haben immernoch ihre eigenen service files. Müssen sie auch, da
distros die teils anders Zusammenfassen und teils andere Packete und
damit andere mögliche Abhängigkeiten haben.
> was vernünftiges Dependency-Management> hat, Services zuverlässig wieder stoppen kann,> sodass die gestarteten Prozesse danach auch tatsächlich weg sind
Auch da gibt es diverse fälle, wo es nicht geht. Wenn z.B. ein Programm
im kernel hängt, so dass nicht mal kill -9 reicht, um es zu beenden,
kann auch systemd nichts mehr ausrichten.
> (dank cgroups, nein, das bietet die Shellskript-Hölle nie, egal wie man es> macht),
Eine cgroup kann man mit einem simplen mkdir Kommando erstellen. Ein
Prozess hinzufügen (z.B. der vom Script vor dem Programmstart), ist mit
einem simplen echo Kommando machbar.
> und als Bonus bootet es noch in endlicher Zeit.
Haha, schln wärs. Sysvinit ist wenigstens Deterministisch.
Sheeva P. schrieb:> Im Übrigen hat es die Entwickler anderer unixoider Systeme auch nie> geschert, ob ihre Software portabel war. SunOS/Solaris, die BSDs, sie> alle hatten und haben ein eigenes Init-System. Warum das jetzt> ausgerechnet den systemd-Entwicklern zum Vorwurf gemacht wird, ist mir> mehr als unverständlich.
Na weil andere init system das Problem nicht haben.
Axel S. schrieb:> systemd bringt> seinen eigenen Zeitsynchronisierungsdienst mit. Sowohl ntpd als auch> ntpdate sind damit obsolet.
Wobei es mittlerweile mindestens 3 verschiedene Zeitservices gibt, denn
neben ntp und systemd-timesync gibts auch noch chrony. Klarerweise
sollte man nur einen davon aktiv haben. Installiert man also ntp, sollte
man nachsehen, ob einer der beiden anderen bereits aktiv ist.
Da systemd-timesync ein reiner sntp Client ist, sind ntp oder chrony
keineswegs obsolet, für lokale Zeitservices oder gleitende Zeitanpassung
ohne Sprünge werden sie weiterhin benötigt.
Miethai schrieb:> Wer nutzt denn noch debian?
Zumindest Leute, die eben kein Desktop System laufen haben, sondern wie
ich, einen reinen Server mit Konsole. Da brauche ich kein Ubuntu,
sondern ein stabiles System ohne Schnick Schnack.
Sven B. schrieb:> Diese Start-Stop-Skripte sind ein Desaster, und> mit den Units vom systemd nicht zu vergleichen. Seit systemd gibt es> endlich ein Init-System, was auf quasi allen Distributionen gleich> funktioniert, was vernünftiges Dependency-Management hat, Services> zuverlässig wieder stoppen kann
SysVinit hat auf meinem Server seit über 15 Jahren bestens funktioniert,
ohne Probleme. Es ist sehr einfach, sich selber Start-Stops zu bauen,
wenn man ein wenig weiss, was man tut.
Ich will einfach nur einen Server, der funktioniert, mit CUPS, netatalk,
Samba, webmin und Apache.
Rolf M. schrieb:> Nur weil die nicht ideal waren, heißt das nicht, dass systemd gut wäre.
Nur weil systemd nicht ideal ist, heißt das nicht, dass "die" gut waren.
;-)
🐧 DPA 🐧 schrieb:> Musste man den Thread nach 4 Jahren wirklich nochmal aufrollen?> Und> mussten die systemd-ist das einzig-wahre fanatiker den wirklich kapern?
Es gibt ja anscheinend noch genug Diskussionsbedarf. Kannst du ein paar
der Fanatiker mit Namen nennen?
> Sven B. schrieb:>> SysVinit gab es ewig lang und es war nie gut.>> Ich finde es immernoch besser als systemd. Aber es gibt ja sonst auch> noch viele Alternativen, z.B. openrc, runit, etc.
Es zwingt dich also niemand dazu systemd zu nutzen.
>> Diese Start-Stop-Skripte>> sind ein Desaster, und mit den Units vom systemd nicht zu vergleichen.>> Seit LSB hat man da auch eine dependency basierte Bootreihenfolge.
Was genau ist LSB? Ich konnte nur
https://en.wikipedia.org/wiki/Linux_Standard_Base finden. Aber das
kannst du ja nicht meinen. Zumindest verstehe ich nicht was Java, GTK,
Cairo und rpm-packages mit init zu zun haben.
> Länger/Komplexer müssen sie auch nicht sein. Dafür sind sie viel> Flexibler. Es gibt auch diverse Ansätze für deklarative, unit ähnliche,> init scripts, z.B. https://github.com/Daniel-Abrecht/unitscript
So flexibel, dass es seit 2 Jahren keinen commit mehr gebraucht hat.
> Eine cgroup kann man mit einem simplen mkdir Kommando erstellen. Ein> Prozess hinzufügen (z.B. der vom Script vor dem Programmstart), ist mit> einem simplen echo Kommando machbar.
Und Zufallszahlen kann man mit cat generieren ...
Ich habe meine Probleme mit systemd, vor allem mit der Doku. Aber für
mich ist es ein Fortschritt gegenüber init-Skripten. Bei mir
funktionieren allerdings auch die Configdateien, die die Distribution
liefert.
Ich bin auch froh, dass es z.B. systemd-boot gibt (ich habe grub keine
Sekunde vermisst). Praktisch ist auch systemd-analyze. Nach ein paar
Sekunden weiß ich warum das Booten heute so lange gedauert hat.
Ich frage mich auch immer, warum so viele von den großen Distributionen
so schnell zu systemd gewechselt sind. Natürlich abgesehen von der
offensichtlichen Antwort.
mh schrieb:> Kannst du ein paar> der Fanatiker mit Namen nennen?
Mit Namen nicht, aber die Leute, die meine kritischen Beiträge
runterwerten, wissen, wer sie sind. Es hat einfach keinen Sinn, solche
Beiträge runterzuwerten, nur weil ihr zu denen gehört, bei denen systemd
funktioniert. Es gibt, wie ja auch die ersten Beiträge schon gezeigt
haben, genug Leute mit Problemen. Und wer sich einmal die Dokumentation
dieses Dings angeschaut hat, weiss wovon ich rede. So ein System sollte
transparent sein, ordentliche Fehlermeldungen machen, damit der mittel
erfahrene User es verstehen und fixen kann. Ich habe einfach keine Zeit
und Lust, wegen so einer emergency Konsole mir die Nächte um die Ohren
zu schlagen, nur für meinen kleinen Server.
Die Ablaufbäume in der Doku sehen ja toll aus, aber die Journale sind
völlig unbrauchbar, was die Fehlersuche angeht. Da sah nämlich alles gut
aus. Und die Hardware des Servers ist auch in Ordnung, wie mir das jetzt
laufende Devuan ja bestätigt.
Warum also die emergency Konsole? Wo läuft was schief? Das war nicht
rauszubekommen. Bei SysVInit sehe ich ein [FAIL], wenn der Service nicht
startet, schön der Reihe nach und ich weiss, wo ich suchen muss.
mh schrieb:>>> Diese Start-Stop-Skripte>>> sind ein Desaster, und mit den Units vom systemd nicht zu vergleichen.>>>> Seit LSB hat man da auch eine dependency basierte Bootreihenfolge.> Was genau ist LSB? Ich konnte nur> https://en.wikipedia.org/wiki/Linux_Standard_Base finden. Aber das> kannst du ja nicht meinen. Zumindest verstehe ich nicht was Java, GTK,> Cairo und rpm-packages mit init zu zun haben.
Von dem Link:
> LSB also specifies boot facilities, such as $local_fs, $network, which are> used to indicate service dependencies in System V-style initialization> scripts. A machine readable comment block at the top of a script provides> the information necessary to determine at which point of the> initialization process the script should be invoked. It is called the LSB> header.
Eventuell etwas kryptisch beschrieben dort, dafür ist "LSB header" dort
schön fett markiert, damit man weiss, wonach man da suchen kann.
mh schrieb:>> Länger/Komplexer müssen sie auch nicht sein. Dafür sind sie viel>> Flexibler. Es gibt auch diverse Ansätze für deklarative, unit ähnliche,>> init scripts, z.B. https://github.com/Daniel-Abrecht/unitscript> So flexibel, dass es seit 2 Jahren keinen commit mehr gebraucht hat.
Das war ein PoC, den ich damals schrieb. Das lightdm Beispielskript dort
im Repo nutze ich immer noch, es hört einfach nicht auf einfach zu
funktionieren. Eventuell sollte ich mal noch 1-2 Features hinzufügen,
ich habe aber im moment wichtigeres zutun.
Warum die Möglichkeit, auch sowas zu machen, deiner Meinung nach aber
nicht für die Flexiblität des sysv-rc Verfahrens spricht, erschliesst
sich mir nicht. Unter Systemd könnte ich nicht einfach so meinen eigenen
Interpreter verwenden.
mh schrieb:> 🐧 DPA 🐧 schrieb:>> Musste man den Thread nach 4 Jahren wirklich nochmal aufrollen?>> Und>> mussten die systemd-ist das einzig-wahre fanatiker den wirklich kapern?>> Es gibt ja anscheinend noch genug Diskussionsbedarf.
Es ging aber doch nie darum, warum Systemd so gut und besser sei. Ich
wollte damals was anderes, ich hab was anderes bekommen, und bin seither
zufrieden.
🐧 DPA 🐧 schrieb:> Unter Systemd könnte ich nicht einfach so meinen eigenen> Interpreter verwenden.
Für einen wie großen Promillsatz der Nutzerschaft hälst du das denn für
relevant?
Le X. schrieb:> 🐧 DPA 🐧 schrieb:>> Unter Systemd könnte ich nicht einfach so meinen eigenen>> Interpreter verwenden.>> Für einen wie großen Promillsatz der Nutzerschaft hälst du das denn für> relevant?
In wiefern spielt das für mein Argument eine Rolle?
🐧 DPA 🐧 schrieb:> Eventuell etwas kryptisch beschrieben dort, dafür ist "LSB header" dort> schön fett markiert, damit man weiss, wonach man da suchen kann.
Oh ja, hab ich übersehen, bei dem ganzen anderen Kram, der nichts damit
zu tun hat. Kein Wunder, dass es sich nicht durchgesetzt hat.
🐧 DPA 🐧 schrieb:> Warum die Möglichkeit, auch sowas zu machen, deiner Meinung nach aber> nicht für die Flexiblität des sysv-rc Verfahrens spricht, erschliesst> sich mir nicht.
Sorry, ich hab mir nicht wirklich angeguckt, was in dem repo steckt. Ich
bin fälschlicherweise, davon ausgegangen, dass das eine Alternative zu
systemd wäre.
🐧 DPA 🐧 schrieb:> Le X. schrieb:>> 🐧 DPA 🐧 schrieb:>>> Unter Systemd könnte ich nicht einfach so meinen eigenen>>> Interpreter verwenden.>>>> Für einen wie großen Promillsatz der Nutzerschaft hälst du das denn für>> relevant?>> In wiefern spielt das für mein Argument eine Rolle?
Weil es zwigt, dass es ein ziemlich schwaches Argument ist?
Ich warte noch auf die Liste mit den Namen.
mh schrieb:> Ich warte noch auf die Liste mit den Namen.
Ich hab keine lust, hier unnötig Konflikte zu erzeugen.
Mikojan Gurewitsch Trocken schrieb:> Daniel A. schrieb:>> [rant]>> Was bedeutet das?
Das ich wütend & genervt war, als ich den Thread eröffnete.
Ich weiss schon, ein Rant, das sollte doch eigentlich dieses grosse
Sinnlose Flammenmeer sein, wo sich alle gedankenlos anschreien. Das war
schon etwas enttäuschend hier in der Hinsicht. Aber ich hab jetzt, nach
4 Jahren, eigentlich auch keine lust, da plötzlich damit anzufangen,
sorry.
🐧 DPA 🐧 schrieb:> mh schrieb:>> Ich warte noch auf die Liste mit den Namen.>> Ich hab keine lust, hier unnötig Konflikte zu erzeugen.
Dafür ist es etwas spät, nachdem du potenziell jeden, der eine andere
Meinung vertritt, als Fanatiker bezeichnet hast.
Ja, ich sehe es ja ein, ich sollte statt systemd lieber systemd
verwenden, meine Meinung war von Anfang an falsch, und es hilft allen
sehr weiter, hier die Verwendung von systemd zu empfehlen. Das sind
alles keine Fanatiker, das sind Engel die fehlgeleitete wie Mich auf den
richtigen weg bringen wollen. Ich bin ja so Kurtssichtig.
🐧 DPA 🐧 schrieb:> Ja, ich sehe es ja ein, ich sollte statt systemd lieber systemd> verwenden, meine Meinung war von Anfang an falsch, und es hilft allen> sehr weiter, hier die Verwendung von systemd zu empfehlen. Das sind> alles keine Fanatiker, das sind Engel die fehlgeleitete wie Mich auf den> richtigen weg bringen wollen. Ich bin ja so Kurtssichtig.
Niemand hat gesagt, dass du systemd benutzen sollst. Niemand hat gesagt,
dass "im systemd Lager" nur Engel sind.
Du hast allerdings geschrieben, dass dieser Thread von systemd
Fanatikern übernommen wurde. Konntest aber bis jetzt nicht sagen, wer
genau diese Fanatiker sind. Soweit ich das beim nochmaligen überfliegen
sehen konnte, hat keiner der systemd Befürworter gesagt, dass systemd
keine Probleme hat, eher das Gegenteil. Sind alle, die systemd aktuell
für die beste real verfügbare Lösung halten, für dich Fanatiker?
Wenn du die Frage nicht beantworten willst, habe ich eine weitere Frage,
die für mich deutlich wichtiger ist. Wie erklärst du, dass nahezu alle
relevanten Linux-Distributionen innerhalb weniger Jahre zu systemd
gewechselt sind?
Ich finde SystemD sollte verpflichtend eingeführt werden. Jeder der
dagegen verstößt sollte aus der Community ausgeschlossen werden und
Beiträge gegen SystemD sollten kommentarlos gelöscht werden...
mh schrieb:> Du hast allerdings geschrieben, dass dieser Thread von systemd> Fanatikern übernommen wurde. Konntest aber bis jetzt nicht sagen, wer> genau diese Fanatiker sind. Soweit ich das beim nochmaligen überfliegen> sehen konnte, hat keiner der systemd Befürworter gesagt, dass systemd> keine Probleme hat, eher das Gegenteil. Sind alle, die systemd aktuell> für die beste real verfügbare Lösung halten, für dich Fanatiker?
Nein. Aber als TO muss man scheuen, dass sein Thread nicht in die
falsche Richtung abdriftet. Wenn ihr die Vor und Nachteile von Systemd
besprechen wollt, ist ein 4 Jahre alter Thread, wo ich genervt davon was
anderes wollte, sicher nicht der ideale Ort dafür.
🐧 DPA 🐧 schrieb:> mh schrieb:>> Du hast allerdings geschrieben, dass dieser Thread von systemd>> Fanatikern übernommen wurde. Konntest aber bis jetzt nicht sagen, wer>> genau diese Fanatiker sind. Soweit ich das beim nochmaligen überfliegen>> sehen konnte, hat keiner der systemd Befürworter gesagt, dass systemd>> keine Probleme hat, eher das Gegenteil. Sind alle, die systemd aktuell>> für die beste real verfügbare Lösung halten, für dich Fanatiker?>> Nein. Aber als TO muss man scheuen, dass sein Thread nicht in die> falsche Richtung abdriftet. Wenn ihr die Vor und Nachteile von Systemd> besprechen wollt, ist ein 4 Jahre alter Thread, wo ich genervt davon was> anderes wollte, sicher nicht der ideale Ort dafür.
Dann solltest du dich eher über Matthias S. (Firma: matzetronics)
(mschoeldgen) aufregen, der den Thread für das genutzt hat, was im Titel
steht. Der Titel stammt von dir, oder?
🐧 DPA 🐧 schrieb:> Sven B. schrieb:>> SysVinit gab es ewig lang und es war nie gut.>> Ich finde es immernoch besser als systemd. Aber es gibt ja sonst auch> noch viele Alternativen, z.B. openrc, runit, etc.
Aber inwiefern denn? Was war denn gut an sysvinit? Was konnte das
tolles? Von einem Init-System erwarte ich doch zumindest, dass es mir
korrekt den Status von einem Service sagen kann. Das kann sysvinit
schonmal nicht, darum muss man sich selbst kümmern. Meh.
> Seit LSB hat man da auch eine dependency basierte Bootreihenfolge.> Länger/Komplexer müssen sie auch nicht sein. Dafür sind sie viel> Flexibler. Es gibt auch diverse Ansätze für deklarative, unit ähnliche,> init scripts, z.B. https://github.com/Daniel-Abrecht/unitscript oder> auch debians init-d-script> (https://manpages.debian.org/stretch/sysvinit-utils/init-d-script.5.en.html)
Warum genau sind diese Skripte irgendwie flexibler? Mir erscheinen sie
nur flexibler darin irgendwas falsch zu machen. Dass irgendeine dritte
Partei eine deklarative Syntax drangeklebt hat, die keiner benutzt,
beeindruckt mich eher nicht.
>> Seit systemd gibt es endlich ein Init-System, was auf quasi allen>> Distributionen gleich funktioniert,>> Die haben immernoch ihre eigenen service files. Müssen sie auch, da> distros die teils anders Zusammenfassen und teils andere Packete und> damit andere mögliche Abhängigkeiten haben.
Mir ja egal. Mich interessiert, dass ich mit "systemctl disable
NetworkManager.service" auf 25 Distros den NetworkManager ausschalten
kann. Das geht jetzt und das ging vorher nie.
> Auch da gibt es diverse fälle, wo es nicht geht. Wenn z.B. ein Programm> im kernel hängt, so dass nicht mal kill -9 reicht, um es zu beenden,> kann auch systemd nichts mehr ausrichten.
Wenn deine CPU anfängt zu brennen, kann systemd auch nichts dagegen tun.
Meh.
>> (dank cgroups, nein, das bietet die Shellskript-Hölle nie, egal wie man es>> macht),>> Eine cgroup kann man mit einem simplen mkdir Kommando erstellen. Ein> Prozess hinzufügen (z.B. der vom Script vor dem Programmstart), ist mit> einem simplen echo Kommando machbar.
Warum macht sysvinit das dann nicht? Genau: weil es sich mit zu viel
Flexibilität in's Bein geschossen hat und das nicht mehr leicht machbar
ist.
>> und als Bonus bootet es noch in endlicher Zeit.>> Haha, schln wärs. Sysvinit ist wenigstens Deterministisch.
systemd ist auch deterministisch wenn du deine Dependencies richtig
angibst.
> Sheeva P. schrieb:>> Im Übrigen hat es die Entwickler anderer unixoider Systeme auch nie>> geschert, ob ihre Software portabel war. SunOS/Solaris, die BSDs, sie>> alle hatten und haben ein eigenes Init-System. Warum das jetzt>> ausgerechnet den systemd-Entwicklern zum Vorwurf gemacht wird, ist mir>> mehr als unverständlich.>> Na weil andere init system das Problem nicht haben.
Hä? Sheeva hat doch gerade Beispiele von Init-Systemen genannt die das
Problem auch haben, in dem Satz, den du zitiert hast.
Sheeva P. schrieb:> Rolf M. schrieb:>> Sven B. schrieb:>>> Seit systemd gibt es endlich ein Init-System, was auf quasi allen>>> Distributionen gleich funktioniert,>>>> Allerdings halt nur unter Linux, weil es absichtlich so gemacht ist,>> dass es auf anderen unixoiden Systemen nicht funktioniert.>> Ich habe gewisse Schwierigkeiten mit der impliziten Unterstellung, daß> systemd mit Absicht darauf ausgelegt sei, auf anderen Systemen nicht zu> funktionieren.
Gut, Inkompatibilität mit anderen Systemen mag vielleicht nicht gerade
das Ziel gewesen sein, aber zumindest wurden diese bei der Entwicklung
gar nicht erst berücksichtigt.
A. K. schrieb:> Axel S. schrieb:>> systemd bringt>> seinen eigenen Zeitsynchronisierungsdienst mit. Sowohl ntpd als auch>> ntpdate sind damit obsolet.
systemd bringt ziemlich viel Zeug mit, das da nicht rein gehört.
> Wobei es mittlerweile mindestens 3 verschiedene Zeitservices gibt, denn> neben ntp und systemd-timesync gibts auch noch chrony. Klarerweise> sollte man nur einen davon aktiv haben. Installiert man also ntp, sollte> man nachsehen, ob einer der beiden anderen bereits aktiv ist.
Oder evtl. braucht man noch genauere Zeitsynchronisation und will lieber
ptp verwenden.
Matthias S. schrieb:> SysVinit hat auf meinem Server seit über 15 Jahren bestens funktioniert,> ohne Probleme. Es ist sehr einfach, sich selber Start-Stops zu bauen,> wenn man ein wenig weiss, was man tut.
Wobei das bei systemd tatsächlich noch einfacher ist.
mh schrieb:>> Seit LSB hat man da auch eine dependency basierte Bootreihenfolge.> Was genau ist LSB? Ich konnte nur> https://en.wikipedia.org/wiki/Linux_Standard_Base finden. Aber das> kannst du ja nicht meinen.
Warum nicht?
> Zumindest verstehe ich nicht was Java, GTK, Cairo und rpm-packages mit init> zu zun haben.
Nichts, würde ich sagen. Java ist übrigens schon seit 9 Jahren nicht
mehr drin.
Dafür sind dort Init-Skripte genormt:
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html
Sven B. schrieb:> 🐧 DPA 🐧 schrieb:>> Sven B. schrieb:>>> SysVinit gab es ewig lang und es war nie gut.>>>> Ich finde es immernoch besser als systemd. Aber es gibt ja sonst auch>> noch viele Alternativen, z.B. openrc, runit, etc.>> Aber inwiefern denn? Was war denn gut an sysvinit? Was konnte das> tolles? Von einem Init-System erwarte ich doch zumindest, dass es mir> korrekt den Status von einem Service sagen kann. Das kann sysvinit> schonmal nicht, darum muss man sich selbst kümmern. Meh.
In dem Sinne kann das systemd auch nicht. Auch dort kann man bei den
unit files Dinge falsch machen.
>> Seit LSB hat man da auch eine dependency basierte Bootreihenfolge.>> Länger/Komplexer müssen sie auch nicht sein. Dafür sind sie viel>> Flexibler. Es gibt auch diverse Ansätze für deklarative, unit ähnliche,>> init scripts, z.B. https://github.com/Daniel-Abrecht/unitscript oder>> auch debians init-d-script>> (https://manpages.debian.org/stretch/sysvinit-utils/init-d-script.5.en.html)>> Warum genau sind diese Skripte irgendwie flexibler?
In scripten kann man alles machen, es gibt keine Grenzen. Noch flexibler
geht nicht.
> Mir erscheinen sie nur flexibler darin irgendwas falsch zu machen. Dass
irgendeine dritte
> Partei eine deklarative Syntax drangeklebt hat, die keiner benutzt,> beeindruckt mich eher nicht.
Es demonstriert, das man Problemlos all die Vorteile von service units
auch mit sysv-rc haben könnte, und dafür nicht das halbe System
übernehmen und ersetzen muss. Sowas hätte man genauso standardisieren
können, wie man es mit systemd gemacht hat, nur ohne den ganzen schaden,
der bei letzterem entstanden ist.
>>> Seit systemd gibt es endlich ein Init-System, was auf quasi allen>>> Distributionen gleich funktioniert,>>>> Die haben immernoch ihre eigenen service files. Müssen sie auch, da>> distros die teils anders Zusammenfassen und teils andere Packete und>> damit andere mögliche Abhängigkeiten haben.>> Mir ja egal. Mich interessiert, dass ich mit "systemctl disable> NetworkManager.service" auf 25 Distros den NetworkManager ausschalten> kann. Das geht jetzt und das ging vorher nie.
Nur um sich auf einen Namen zu einigen, braucht man kein systemd. Und
wenn man ein allgemeines Kommando dafür einfüren hätte wollen, hätte man
das auch z.B. mit einem freedesktop standard oder so machen können. Das
hätte auch weniger Probleme verursacht, als so fundamental zu verändern,
wie alles funktioniert, wie das nun gemacht wurde, und wäre sogar init
system agnostisch gewesen.
>> Auch da gibt es diverse fälle, wo es nicht geht. Wenn z.B. ein Programm>> im kernel hängt, so dass nicht mal kill -9 reicht, um es zu beenden,>> kann auch systemd nichts mehr ausrichten.>> Wenn deine CPU anfängt zu brennen, kann systemd auch nichts dagegen tun.> Meh.>>>> (dank cgroups, nein, das bietet die Shellskript-Hölle nie, egal wie man es>>> macht),>>>> Eine cgroup kann man mit einem simplen mkdir Kommando erstellen. Ein>> Prozess hinzufügen (z.B. der vom Script vor dem Programmstart), ist mit>> einem simplen echo Kommando machbar.>> Warum macht sysvinit das dann nicht? Genau: weil es sich mit zu viel> Flexibilität in's Bein geschossen hat und das nicht mehr leicht machbar> ist.
Normalerweise braucht man es schlicht nicht. Wenn man es braucht, kann
man es haben. Nur weil es nicht der default ist, geht die Welt auch
nicht unter. Bei manchen Anwendungen würde es ausserdem auch zu
Problemen führen. z.B. wenn ich per ssh auf einem Server eingelogd bin,
mache ein update, und schalte das Killen aller Prozesse für ssh nicht
aus, wird mich der ssh restart schön nach dem Stoppen rauswerfen, was
problematisch sein kann. Änliches gäbe es sicher auch bei vielen anderen
Netzwerkdiensten.
>>> und als Bonus bootet es noch in endlicher Zeit.>>>> Haha, schln wärs. Sysvinit ist wenigstens Deterministisch.>> systemd ist auch deterministisch wenn du deine Dependencies richtig> angibst.
Ja klar, jetzt ist es plötzlich kein Nachteil mehr, wenn es einfacher
wird, sich selbst in den Fuss zu schiessen. Bei Sysvinit hat man selbst
bei falschen dependencies, und bei jedem reboot, eine fixe Reihenfolge,
in der die Dinge starten. (kann man zwar glaub ich auch ausschalten ;)
). Klar, das kann dann gehen oder auch nicht, aber ob es das tut, ändert
sich zwischen Reboots nicht.
>> Sheeva P. schrieb:>>> Im Übrigen hat es die Entwickler anderer unixoider Systeme auch nie>>> geschert, ob ihre Software portabel war. SunOS/Solaris, die BSDs, sie>>> alle hatten und haben ein eigenes Init-System. Warum das jetzt>>> ausgerechnet den systemd-Entwicklern zum Vorwurf gemacht wird, ist mir>>> mehr als unverständlich.>>>> Na weil andere init system das Problem nicht haben.>> Hä? Sheeva hat doch gerade Beispiele von Init-Systemen genannt die das> Problem auch haben, in dem Satz, den du zitiert hast.
Die sind die ausnahme. OpenRC, runit, etc. könnte man auch unter z.B.
einem BSD laufen lassen.
Bezüglichn BSD Init, zumindest bei FreeBSD, scheint der rc teil davon
tatsächlich nur ein risen shell skript zu sein, plus dieses kleine
rcorder program. Viel Platformspezifisches sehe ich dort nicht, der
Aufwand das auf ein anderes System zu portieren, dürfte sehr minimal
sein. Besonders sinvoll wäre es zwar vermutlich aber nicht.
🐧 DPA 🐧 schrieb:> Sowas hätte man genauso standardisieren können, wie man es mit systemd> gemacht hat, nur ohne den ganzen schaden, der bei letzterem entstanden ist.🐧 DPA 🐧 schrieb:> Nur um sich auf einen Namen zu einigen, braucht man kein systemd. Und> wenn man ein allgemeines Kommando dafür einfüren hätte wollen, hätte man> das auch z.B. mit einem freedesktop standard oder so machen können.
Hätte, hätte ... hat aber niemand überzeugend getan, oder warum benutzen
nahezu alle Distris systemd?
🐧 DPA 🐧 schrieb:>> Aber inwiefern denn? Was war denn gut an sysvinit? Was konnte das>> tolles? Von einem Init-System erwarte ich doch zumindest, dass es mir>> korrekt den Status von einem Service sagen kann. Das kann sysvinit>> schonmal nicht, darum muss man sich selbst kümmern. Meh.>> In dem Sinne kann das systemd auch nicht. Auch dort kann man bei den> unit files Dinge falsch machen.
Aber das nicht: die Prozesse, die irgendwie von dieser Unit gestartet
werden, sind in der CGroup von der Unit, und wenn ich die Unit stoppe,
werden die gestoppt oder ich kriege zumindest mit, wenn sie noch laufen.
> In scripten kann man alles machen, es gibt keine Grenzen. Noch flexibler> geht nicht.
Mit den systemd-Units kann ich ein Skript starten, wenn noetig ...
> Es demonstriert, das man Problemlos all die Vorteile von service units> auch mit sysv-rc haben könnte, und dafür nicht das halbe System> übernehmen und ersetzen muss. Sowas hätte man genauso standardisieren> können, wie man es mit systemd gemacht hat, nur ohne den ganzen schaden,> der bei letzterem entstanden ist.
Das bestreite ich nicht. systemd hat definitiv scope creep. Das ist
besonders schlimm an den Stellen, wo irgendwas hingebastelt wurde an
einem Wochenende und dann nie wieder verbessert -- z.B. systemd-networkd
ist ein Desaster.
> Nur um sich auf einen Namen zu einigen, braucht man kein systemd. Und> wenn man ein allgemeines Kommando dafür einfüren hätte wollen, hätte man> das auch z.B. mit einem freedesktop standard oder so machen können.
Ja hätte hätte, aber hat keiner gemacht, obwohl 25 Jahre Zeit waren ;)
Ich begrüße einfach nur die Lösung, die das endlich geschafft hat ...
> Normalerweise braucht man es schlicht nicht. Wenn man es braucht, kann> man es haben. Nur weil es nicht der default ist, geht die Welt auch> nicht unter.
Smart-Pointer in C++ braucht man auch nicht. Aber wenn man vergisst was
wieder wegzuräumen, ist man halt am Suchen. Genau dieselbe Situation
gilt auch für die Prozesse ...
> Ja klar, jetzt ist es plötzlich kein Nachteil mehr, wenn es einfacher> wird, sich selbst in den Fuss zu schiessen. Bei Sysvinit hat man selbst> bei falschen dependencies, und bei jedem reboot, eine fixe Reihenfolge,> in der die Dinge starten.
Naja, du kriegst halt einen ordentlichen Gegenwert, der diesen Nachteil
aufwiegt, nämlich ist das Starten zehnmal so schnell ;)
Sven B. schrieb:> Aber das nicht: die Prozesse, die irgendwie von dieser Unit gestartet> werden, sind in der CGroup von der Unit, und wenn ich die Unit stoppe,> werden die gestoppt oder ich kriege zumindest mit, wenn sie noch laufen.
Ok, ja, um soetwas unter sysv hinzubekommen bräuchte man ein Launcher
Program das das erledigen kann, und müsste die Nutzer umgewöhnen, dass
die Scripts nicht direkt aufgerufen werden. Da fehlt in der tat eine
standardisierte Zwischenschicht zwischen User und Skriptaufruf, um sowas
machen zu können.
Andererseits haben wir es in unserem unternehmen aber immer noch nicht
geschafft, allen beizubringen, ihre Anwendungen nicht an systemd vorbei
selbst zu starten. Vollständig kann sowas das Nachschauen ob ein Prozess
läuft mit ps & co. halt leider doch nicht ersetzen.
Sven B. schrieb:> Von einem Init-System erwarte ich doch zumindest, dass es mir> korrekt den Status von einem Service sagen kann. Das kann sysvinit> schonmal nicht, darum muss man sich selbst kümmern. Meh.
So? Das kann systemd aber auch nicht, bzw. es benutzt das gleiche
Prinzip wie SysVInit - es guckt, ob es einen Prozess gibt, der so
heisst. Und ja, das kann SysVInit auch, wenn es das jeweilige Skript
unterstützt.
Zusätzlich gibt es einen sauber dokumentierten Systemstart, der mir für
einen Server viel wichtiger ist als ein paar Sekunden Zeitgewinn durchs
Parallelisieren - m.E. der einzige Vorteil von systemd.
Aber ich persönlich kann mit den Journals nichts anfangen - bzw. ich
konnte keinen Grund dafür finden, warum der Rechner auf dem Emergency
Target endet. Es war auch nach langem Suchen in den Journals nichts
dramatisch falsches zu finden. Und dann hast du irgendwann keinen Nerv
mehr für den Mist - ich will einfach nur, das die Kiste normal startet.
Das ist ja auch kein Quantencomputer, sondern ein kleiner ITX-220 mit
2GB RAM, der sonst immer prima gelaufen ist.
Sven B. schrieb:> Naja, du kriegst halt einen ordentlichen Gegenwert, der diesen Nachteil> aufwiegt, nämlich ist das Starten zehnmal so schnell ;)
Das zählt für mich überhaupt nicht.
(öffentlicher Web-, VPN- und Mail-Server, mit einigen tausend Besuchern
pro Tag)
EDIT:
Hier noch ein anderer, mit ähnlichen Aufgaben:
$ uptime
13:43:53 up 1156 days, 11:19, 2 users, load average: 0.09, 0.10, 0.13
Wenn diese Server gebootet werden müssten, dann nur, weil es vorher ein
erhebliches (Hardware-)Problem gab, dessen Behebung erheblich mehr Zeit
benötigte als das anschließende Booten. In beiden Systemen werden 4 bzw.
8 chroot-Umgebungen eingesetzt, welche sich mit systemd überhaupt nicht
vertragen. Daher werden die Dienste in den chroots in SYSV-init-Mimik
per selbstgebautem Script gestartet und gestoppt. Jaja, es gibt auch so
etwas wie Docker... aber das ist nicht das Thema.
Frank M. schrieb:> (öffentlicher Web-, VPN- und Mail-Server, mit einigen tausend Besuchern> pro Tag)
Bei Servern sind aber gelegentlich Fixes dabei, für die man auch Linux
neu starten sollte. Besonders bei öffentlichen.
Frank M. schrieb:> (öffentlicher Web-, VPN- und Mail-Server, mit einigen tausend Besuchern> pro Tag)
Wer so einen Server betreibt hat dann ja auch kein Problem eine der
genannten super tollen Alternativen zu installieren.
Ich persönlich erwarte von meinem Computer, dass er 20 Sekunden nachdem
ich auf den Knopf drücke zu 100% einsatzbereit ist. Das ist mit systemd
gerade so möglich.
mh schrieb:> Ich persönlich erwarte von meinem Computer, dass er 20 Sekunden nachdem> ich auf den Knopf drücke zu 100% einsatzbereit ist.
Bei Servern (aus Blech) kann es etliche Minuten dauern, bis sich die
Kiste überhaupt dem Start vom Betriebssystem widmet. Am anderen Ende der
Skala sind Notebooks, bei denen es sich oft nicht lohnt, sie ganz
abzuschalten, und bei denen es ein paar Sekunden dauern kann, bis das
WLAN oben ist.
A. K. schrieb:> mh schrieb:>> Ich persönlich erwarte von meinem Computer, dass er 20 Sekunden nachdem>> ich auf den Knopf drücke zu 100% einsatzbereit ist.>> Bei Servern (aus Blech) kann es etliche Minuten dauern, bis sich die> Kiste überhaupt dem Start vom Betriebssystem widmet. Am anderen Ende der> Skala sind Notebooks, bei denen es sich oft nicht lohnt, sie ganz> abzuschalten, und bei denen es ein paar Sekunden dauern kann, bis das> WLAN oben ist.
Das ist mir klar. Wer so einen Server betreibt, kann doch problemlos
eine Alternative zu systemd installieren. Wenn man das nicht kann,
sollte man auch keine Server im Internet betreiben. Es ist also kein
besonders starkes Argument gegen systemd.
Und nur weil es sich bei ein paar Notebooks lohnen könnte, sie nicht
abzuschalten, schadet es nicht Dinge parallel zu starten, wenn ein
Neustart nötig ist. Was ist mit denen, die mehrmals täglich booten
müssen?
Nur weil es in ein paar Sonderfällen nicht gebraucht wird, ist es
schlecht? Oder was ist hier das Argument?
mh schrieb:> Es ist also kein besonders starkes Argument gegen systemd.
Die Bootzeit spielt bei solchen Systemen offensichtlich keine Rolle,
weshalb es darauf bezogen egal ist, ob systemd oder nicht.
Wobei die Laufzeit von Reboots bei den heute meist virtuellen Servern
schon interessant sein kann. Wenn der bloss ~10 Sekunden dauert (debian
10), kann man Patch-Reboots vieler Server oft mittendrin durchführen,
ohne erst langwierig koordinieren zu müssen.
A. K. schrieb:> mh schrieb:>> Es ist also kein besonders starkes Argument gegen systemd.>> Die Bootzeit spielt bei solchen Systemen offensichtlich keine Rolle,> weshalb es darauf bezogen egal ist, ob systemd oder nicht.>> Wobei die Laufzeit von Reboots bei den heute meist virtuellen Servern> schon interessant sein kann. Wenn der bloss ~10 Sekunden dauert (debian> 10), kann man Patch-Reboots vieler Server oft mittendrin durchführen,> ohne erst langwierig koordinieren zu müssen.
Wir sind also bei einem Vorteil vom parallel starten angekommen.
mh schrieb:> Wir sind also bei einem Vorteil vom parallel starten angekommen
An der Stelle schon. Aber auf ein paar Sekunden kommts da nicht an.
Reboots von praktisch blanken VMs zum Vergleich, jeweils bis Prompt.
debian 9: 10s
devian 9: 20s
Win 2019: 23s
mh schrieb:> Es ist also kein besonders starkes Argument gegen systemd.
Und wieso müssen wir nochmal für oder gegen Systemd argumentieren? Warum
ist euch Systemd so wichtig, dass ihr nicht akzeptieren wollt, das es
einigen nicht gefällt, und stattdessen lieber etwas anderes benutzen?
Warum haben es andere nötig, sich willkürlich Argumente gegen
alternativen auszudenken, mit denen deren momentanen Nutzer doch
zufrieden sind?
A. K. schrieb:> Wobei die Laufzeit von Reboots bei den heute meist virtuellen Servern> schon interessant sein kann. Wenn der bloss ~10 Sekunden dauert (debian> 10), kann man Patch-Reboots vieler Server oft mittendrin durchführen,> ohne erst langwierig koordinieren zu müssen.
Dann scheint da nicht wichtiges drauf zu laufen.
🐧 DPA 🐧 schrieb:> Und wieso müssen wir nochmal für oder gegen Systemd argumentieren? Warum> ist euch Systemd so wichtig, dass ihr nicht akzeptieren wollt, das es> einigen nicht gefällt, und stattdessen lieber etwas anderes benutzen?
Es hat niemand etwas dagegen, wenn Alternativen zu systemd benutzt
werden. Wenn du genau lesen würdes was ich bis jetzt geschrieben hab,
steht da sogar das Gegenteil. Aber warum sollte ich nicht auf Threads
antworten, in denen fehlerhafte Argumente genutzt oder falsche
Behauptungen aufgestellt werden, um diese zu korrigieren? Klar es gibt
immer die ein oder andere Person, die sich nicht korrigieren lassen
will...
A. K. schrieb:> mh schrieb:>> Ich persönlich erwarte von meinem Computer, dass er 20 Sekunden nachdem>> ich auf den Knopf drücke zu 100% einsatzbereit ist.>> Bei Servern (aus Blech) kann es etliche Minuten dauern, bis sich die> Kiste überhaupt dem Start vom Betriebssystem widmet. Am anderen Ende der> Skala sind Notebooks, bei denen es sich oft nicht lohnt, sie ganz> abzuschalten, und bei denen es ein paar Sekunden dauern kann, bis das> WLAN oben ist.
Die schalte ich meist nicht aus, sondern nur in den Standby
(Suspend-to-RAM). Dann ist der Rechner innerhalb von vielleicht zwei
Sekunden bereit. Natürlich braucht er kontinuierlich etwas Strom, d.h.
wenn er nicht am Stromnetz hängt, geht das nur begrenzt. Bei mir reicht
der Akku aber so ca. für eine Woche Standby.
Rolf M. schrieb:> Die schalte ich meist nicht aus, sondern nur in den Standby> (Suspend-to-RAM).
Ich auch. Allerdings geht nach einer Weile im Standby die WLAN
Verbindung flöten und wird nach dem Aufwachen neu aufgebaut. Und das
braucht halt ein paar Sekunden.
Das hängt wahrscheinlich auch sehr vom Gerät ab. Ich hab's grad mal
ausprobiert, und es scheint bei mir zumindest länger zu dauern, als ich
brauche, um das Passwort zum Desktop entsperren einzugeben.
Sven B. schrieb:> Das bestreite ich nicht. systemd hat definitiv scope creep. Das ist> besonders schlimm an den Stellen, wo irgendwas hingebastelt wurde an> einem Wochenende und dann nie wieder verbessert -- z.B. systemd-networkd> ist ein Desaster.
...und das gilt (galt, als ich mir systemd das erste und letzte Mal
angeschaut habe) in noch höherem Maß für die Dokumentation. Viele Dinge
in systemd sahen aus, als wären sie nach folgendem Muster entstanden:
1) Oh, $Fremdsoftware ist ja unbequem zu bedienen/zu langsam/arbeitet
nicht so mit systemd zusammen, wie ich das will
2) Ich implementier mal die 2% der Funktionalität von $Fremdsoftware in
systemd, die ich brauche. So, dass $Fremdsoftware danach nicht mehr
zusammen mit systemd läuft.
3) Die anderen 98% braucht ja eh keiner. Also ich nicht.
4) Dokumentation? Wer braucht schon Dokumentation?
5) Jetzt ist die Funktion viel, viel besser! Also statt 1s braucht es
jetzt 0,8s bei mir. Meistens. Manchmal auch 2s.
Nee, ich hab irgendwann vor 7-8 Jahren dann auch den Raspberry Pi auf
Slackware migriert, nachdem das Arch-Update mir einen nicht vollständig
bootenden Rechner hinterlassen hat, der nichtmal journalctl ausführen
konnte, also mangels Logfiles auch nicht vernünftig zu debuggen war.
Archlinux war sicher auch nicht die stabilste Distribution...
Mag sein, dass das nur die Gewohnheit ist, aber so ein BSD-Style init
mit separaten Programmen mit separaten Manpages und separater
Konfiguration ist für mich viel viel einfacher zu durchschauen als
alles, was systemd da mit seinen Unit Files so anstellt. Ohne dass es
mir irgendwelche Nachteile einbringt.
MfG, Arno
Arno schrieb:> ...und das gilt (galt, als ich mir systemd das erste und letzte Mal> angeschaut habe) in noch höherem Maß für die Dokumentation. Viele Dinge> in systemd sahen aus, als wären sie nach folgendem Muster entstanden:
Und da ist der nächste mit einem "rant". Er gibt sogar zu, dass er
eigentlich keine Ahnung hat, da sein "Wissen" mittlerweile 7-8 Jahre alt
ist (systemd ist ~10).
Arno schrieb:> Nee, ich hab irgendwann vor 7-8 Jahren dann auch den Raspberry Pi auf> Slackware migriert, nachdem das Arch-Update mir einen nicht vollständig> bootenden Rechner hinterlassen hat, der nichtmal journalctl ausführen> konnte, also mangels Logfiles auch nicht vernünftig zu debuggen war.> Archlinux war sicher auch nicht die stabilste Distribution...
Und dann stellt er selbst fest, dass vielleicht doch die Distribution
schuld ist, da mal wieder ein Update schief gegangen ist.
Arno schrieb:> Viele Dinge> in systemd sahen aus, als wären sie nach folgendem Muster entstanden:
Naja, das finde ich jetzt etwas polemisch. Die Kernkomponenten, also das
Journal und die Units, sind eigentlich sehr reich an Funktionen und
nicht exzellent, aber ausreichend gut dokumentiert. Problematisch finde
ich wie gesagt eher so den Addon-Kram.
Rolf M. schrieb:> Das hängt wahrscheinlich auch sehr vom Gerät ab. Ich hab's grad mal> ausprobiert, und es scheint bei mir zumindest länger zu dauern, als ich> brauche, um das Passwort zum Desktop entsperren einzugeben.
Sorry, ich meinte "...scheint bei mir zumindest nicht länger zu
dauern..."
🐧 DPA 🐧 schrieb:> Warum> ist euch Systemd so wichtig, dass ihr nicht akzeptieren wollt, das es> einigen nicht gefällt, und stattdessen lieber etwas anderes benutzen?
Wenn du mal aufmerksam schaust, wirst du sehen, dass nahezu keine dieser
Diskussionen von einem systemd-User angestoßen wird, der nicht
akzeptieren wollte, dass es Alternativen gibt, sondern von Leuten, die
ein Problem mit systemd haben und/oder die Alternativen propagieren
möchten. Richtig müsste obige Frage also lauten:
„Warum stört euch systemd so sehr, dass ihr nicht akzeptieren wollt,
dass die meisten damit prima klarkommen und gar nichts anderes nutzen
wollen?“
Zumal die meisten „Argumente“ ja auch eher irgendwo aufgeschnappt wurden
und für diejenigen eigentlich nicht einmal relevant wären, während ein
anderer guter Teil schlicht auf die Weigerung zurückzuführen ist, mal
The Friendly Manual zu lesen. Natürlich haben einige auch tatsächliche
Probleme, die sich für sie nicht lösen lassen – dann sollen sie halt was
nehmen, das besser in ihr Szenario passt. Ich, als bekennender
systemd-User, habe damit überhaupt gar kein Problem, und kann das
vollkommen und ohne Vorbehalte akzeptieren – so unglaublich das nun auch
klingen mag.
mh schrieb:> Und dann stellt er selbst fest, dass vielleicht doch die Distribution> schuld ist, da mal wieder ein Update schief gegangen ist.
Das ist mir, ehrlich gesagt, völlig wurscht. Wenn es die Distri nicht
schafft, ein funktionierendes SysVInit auf systemd umzuschnurzeln, dann
ist zumindest der Ärger da und man wundert sich, warum eine simple
Distro wie z.B. Debian Server es nicht schafft. Immerhin waren sie es
ja, die systemd eingeführt haben - scheinen aber zumindest auf meinem
System es nicht zu schaffen. Ob es an Debian oder systemd liegt, ist mir
egal, aber systemd war nun eindeutig die Fehlerursache.
Sven B. schrieb:> nicht exzellent, aber ausreichend gut dokumentiert
Ich mag keine grosse Softwareleuchte sein, aber ich fahre seit über 20
Jahren Linux (beginnend mit Slackware, Kontributor bei uCLinux), kann
man-Pages abrufen und auch die Dokumentation von systemd durchblättern,
um ein Problem zu lösen. Aber der Dokumentation mangelt es eindeutig an
Transparenz:
* Welche Applikation ist denn nun 'init' (also PID 1)?
* Woran erkennt man in 'journalctl - xb' oder 'journalctl -xe', welcher
Job nun dafür sorgt, das bei mir aufs emergency.target abgebogen wird
und nicht aufs gewünschte multi-user.target?
Und das sind nur ein paar Fragen, die mir jetzt noch einfallen.
Die systemd Doku ist da nicht hilfreich und weder ein 'journalctl' noch
syslog und dmesg waren dabei eine Hilfe.
Wie o.a. hatte ich die Schnauze nach der durchgearbeiteten Nacht voll,
ganz im Sinne des Thread Titels.
Ich war dankbar, das hier die Devuan Alternative erwähnt wurde und habe
das gepostet.
Matthias S. schrieb:> eine simple> Distro wie z.B. Debian Server
Es gibt kein Release namens „Debian Server“. War’s vielleicht ein
Derivat, wie die *buntus? Vielleicht gar noch so’n „nach
Feierabend“-Projekt, wie Mint?
Matthias S. schrieb:> * Welche Applikation ist denn nun 'init' (also PID 1)?
ps wird’s dir verraten:
root 1 0.0 0.1 118412 11736 ? Ss Sep18 0:02
/usr/lib/systemd/systemd
Matthias S. schrieb:> * Woran erkennt man in 'journalctl - xb' oder 'journalctl -xe', welcher> Job nun dafür sorgt, das bei mir aufs emergency.target abgebogen wird> und nicht aufs gewünschte multi-user.target?
Üblicherweise schränkt man bei der Fehlersuche die Ausgabe nur genau
dann ein, wenn man weiß, dass man die ausgeblendeten Sachen nicht
braucht. Entsprechend würde ich hier, wenn es mit den Einschränkungen
durch -xb oder -xe nicht festzumachen ist, diese mal weglassen.
Matthias S. schrieb:> mh schrieb:>> Und dann stellt er selbst fest, dass vielleicht doch die Distribution>> schuld ist, da mal wieder ein Update schief gegangen ist.>> Das ist mir, ehrlich gesagt, völlig wurscht.
Das ist mittlerweile klar. Du gibst ja selbst zu, dass du das Problem
nicht identifizieren konntest. Und anscheind suchst du die Schuld bei
systemd, weil
Matthias S. schrieb:> 'journalctl - xb' oder 'journalctl -xe'
dir nicht direkt die Lösung geliefert hat.
Wenn ich jedes mal systemd die Schuld geben würde, wenn das Log mal
wieder keine Infos enthält warum einer der Rechenknechte ohne
menschliche Hilfe neugestartet hat, würde ich vermutlich auch systemd
hassen.
Jack V. schrieb:> Es gibt kein Release namens „Debian Server“
Es gibt aber eine Installationsauswahl beim 'netinst' Image namens
'Server', bei dem kein X und kein Office- und Webkrams installiert wird.
Ich habe aber den Eindruck, das du nur Haare in der Suppe suchst.
> Entsprechend würde ich hier, wenn es mit den Einschränkungen> durch -xb oder -xe nicht festzumachen ist, diese mal weglassen.
Ja super. 'journalctl -xb' war aber genau das, was mir die spärliche
Hilfe des emergency Targets vorgeschlagen hat. Woher soll ich denn
wissen, das sowas nur ein Spass ist und gar nicht hilft? Es hätte ja
auch gereicht, wenn mir gesagt wurde 'Exit Code Fehler im Modul
sowienoch', das hätte sicher geholfen.
Du siehst also, das systemd einen im Regen stehen lässt, selbst, wenn es
einen kleinen Fehler zu geben scheint (mehr wars bestimmt nicht). So ein
'System' kann ich hier nicht brauchen.
Matthias S. schrieb:> Es gibt aber eine Installationsauswahl beim 'netinst' Image namens> 'Server', bei dem kein X und kein Office- und Webkrams installiert wird.> Ich habe aber den Eindruck, das du nur Haare in der Suppe suchst.
Nein, ich suche keine Haare. Ich gehe nur davon aus: wenn jemand schon
nicht korrekt benennt, was er da eigentlich benutzt, dann wird’s beim
weiteren Verständnis möglicherweise auch Defizite geben. Zumindest ich
neige in dem Fall dazu, zunächst ein Layer-8-Problem anzunehmen.
Matthias S. schrieb:> Ja super. 'journalctl -xb' war aber genau das, was mir die spärliche> Hilfe des emergency Targets vorgeschlagen hat. Woher soll ich denn> wissen, das sowas nur ein Spass ist und gar nicht hilft?
Ja super – das steht im Manual. Sollte man mal drübergeschaut haben,
wenn man Server betreiben will.
Matthias S. schrieb:> Du siehst also, das systemd einen im Regen stehen lässt, selbst, wenn es> einen kleinen Fehler zu geben scheint (mehr wars bestimmt nicht). So ein> 'System' kann ich hier nicht brauchen.
… die interessante Frage in dem Kontext ist: gibt ein SysV-Init samt
rsyslogd dir da tatsächlich mehr/detailliertere Informationen, oder
schaust du dort dann doch eher direkt ins Log? Wenn Letzteres: warum ist
das da okay, und bei systemd/journald nicht?
Jack V. schrieb:> gibt ein SysV-Init samt> rsyslogd dir da tatsächlich mehr/detailliertere Informationen
Ja, natürlich. Da sehe ich beim Starten direkt auf der Konsole ein
[Failed] beim zu startenden Dienst, rot eingefärbt im Gegensatz zu den
grünen mit [OK].
Da siehst du sofort, wenn was nicht stimmt. Übrigens hilft bei SysV ein
Blick ins Syslog oder dmesg, was es bei systemd nicht tut, es wird
nichts eingetragen, was bei der Fehlersuche helfen könnte.
Jack V. schrieb:> Ja super – das steht im Manual
Sishste, da isses wieder, das tolle aber nutzlose Argument. Die
Dokumentation ist aber unbrauchbar für systemd Neulinge und hilft einem
nichts. Wie o.a., habe ich fast die ganze Nacht dran gesessen - hätte
ich mal lieber gleich Devuan installiert.
Jack V. schrieb:> Sollte man mal drübergeschaut haben,> wenn man Server betreiben will.
Arrogant bist du gar nicht, oder? Ja ich betreibe einen Server, aber
nicht gezwungenermaßen mit systemd. Und ich bin auch kein SuperAdmin,
sondern ein mittelmässig erfahrener Linux Benutzer.
Für mich ist das übrigens hier abgeschlossen, die Fanboys versuchen
wieder mal, den Mist zu verteidigen, nur weil ich Luft abgelassen habe,
wie der Thread Titel eben auch vorschlägt.
Matthias S. schrieb:> Ja, natürlich. Da sehe ich beim Starten direkt auf der Konsole ein> [Failed] beim zu startenden Dienst, rot eingefärbt im Gegensatz zu den> grünen mit [OK].
Genau das habe ich mit journald/systemd auch. Und nun?
Das Failed/OK mit den hübschen Farben kommt übrigens nicht vom syslogd
oder dem Initsystem, sondern ist vom Distributor gescriptet worden. SuSE
war da damals Vorreiter, der Rest hat’s dann nach und nach übernommen.
Bei Debian kam es relativ spät an.
Matthias S. schrieb:> Übrigens hilft bei SysV ein> Blick ins Syslog oder dmesg, was es bei systemd nicht tut, es wird> nichts eingetragen, was bei der Fehlersuche helfen könnte.
Es wird genau das Gleiche eingetragen. Und im Journal steht dann noch
erheblich mehr an Informationen, als man beim rsylogd je hatte. Weil
systemd, im Gegensatz zum SysV-Init, den Kram auch ein wenig trackt.
Solche Filteroptionen wie -xe/xb und die ganzen anderen Möglichkeiten
hast du beim SysV/rsyslog nicht mal – da malt jeder ins Log, wie er
lustig ist, und du kanns es dir greppen – wenn du weißt, was du suchst.
Matthias S. schrieb:> Sishste, da isses wieder, das tolle aber nutzlose Argument. Die> Dokumentation ist aber unbrauchbar für systemd Neulinge und hilft einem> nichts.
Nicht? Wenn ich eine Sache nicht verstehe, ist diese Sache Schuld, dass
ich sie nicht verstehe? Also ich persönlich sehe das nur in sehr wenigen
Bereichen so – Politik, etwa – und sehe ansonsten das Defizit auf meiner
Seite. Und versuche, es zu beheben.
Matthias S. schrieb:> hätte> ich mal lieber gleich Devuan installiert.
Warum hast du nicht? Damit ist nichts verkehrt – die Wahl lag jedoch
alleine bei dir. Hattest du dich vorher nicht informiert?
Matthias S. schrieb:> Arrogant bist du gar nicht, oder?
Nein. Ich bekomme nur immer das Spucken, wenn ich in die Logs (journald,
btw. – sehr ausführlich und extrem gut filterbar) meiner Server gucke
und sehe, wie viele aufgemachte Dosen wieder mit ihren Scripten da
aufgeschlagen sind, weil sie von wenig erfahrenen Usern betrieben
werden, denen es als Zumutung erscheint, im Vorfeld mal ’nen Blick in
die verfügbare Doku zu werfen, um zu verstehen, wie die Dinge überhaupt
zusammenhängen.
Matthias S. schrieb:> Für mich ist das übrigens hier abgeschlossen, die Fanboys versuchen> wieder mal, den Mist zu verteidigen, nur weil ich Luft abgelassen habe
Warum nimmst du eigentlich nicht Windows Server? Funktioniert auch, mit
umfangreichem Logging wirst du da nicht belästigt, und es gibt
beschriftete Schaltflächen zum Draufklicken.
Jack V. schrieb:> Warum nimmst du eigentlich nicht Windows Server? Funktioniert auch, mit> umfangreichem Logging wirst du da nicht belästigt,
Der Windows Server loggt reichlich, das schenkt sich nichts. Auch nicht,
ob man Linux-Logs oder Windows-Logs in Elasticsearch/Logstash/Kibana
sammelt. Windows-Logs sind aber etwas besser formalisiert als
Syslog-Einträge.
Mangels praktischer Erfahrungen nehme ich die Aussagen zum Logging unter
Windows Server mal so hin. Allerdings:
A. K. schrieb:> Windows-Logs sind aber etwas besser formalisiert als> Syslog-Einträge.
Diese Sache versucht journald ja zu kompensieren. Da kannst du recht
feingranular suchen und ausgeben lassen.
Thread beobachten
Seitenaufteilung abschalten