Forum: PC Hard- und Software [rant] SystemD, jetzt reichts!


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Daniel A. (daniel-a)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
[Unit]
Description=Postfix Mail Transport Agent
After=network.target
Conflicts=sendmail.service exim4.service
ConditionPathExists=/etc/postfix/main.cf

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true

[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:
# Automatically Generated by opendkim systemd service file generator.
# To change the editable parameters, edit /etc/default/opendkim and then do
# systemctl restart opendkim.

# If you are using OpenDKIM with SQL datasets it might be necessary to start
# OpenDKIM after the database servers. For example, if using both MariaDB and
# PostgreSQL, edit /etc/default/opendkim to add the needed definitions to
# EXTRAAFTER. If used, mariadb.service and postgresql.service would have to be
# added.

[Unit]
Description=OpenDKIM DomainKeys Identified Mail (DKIM) Milter
Documentation=man:opendkim(8) man:opendkim.conf(5) man:opendkim-genkey(8) man:opendkim-genzone(8) man:opendkim-testadsp(8) man:opendkim-testkey http://www.opendkim.org/docs.html
After=network.target nss-lookup.target 

[Service]
Type=forking
PIDFile=
PermissionsStartOnly=true
User=opendkim
Group=
ExecStartPre=-/bin/sh /lib/opendkim/opendkim.service.generate
ExecStartPre=-/bin/mkdir -p
ExecStartPre=-/bin/chown opendkim.
ExecStart=/usr/sbin/opendkim -p local:/var/spool/postfix/var/run/opendkim/opendkim.sock  -x /etc/opendkim.conf -u opendkim -P
TimeoutStartSec=10
ExecReload=/bin/kill -USR1 $MAINPID

[Install]
WantedBy=multi-user.target

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.

: Verschoben durch Admin
von Georg A. (georga)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Kaj G. (Firma: RUB) (bloody)


Bewertung
2 lesenswert
nicht lesenswert
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:OpenRC
https://wiki.manjaro.org/index.php?title=OpenRC,_an_alternative_to_systemd
OpenRC, an alternative to systemd

OpenRC is a dependency based init system maintained by the Gentoo
developers, that works with the system provided init program, normally
sysvinit. It is not a replacement for sysvinit.

It is an alternative to systemd for users that like more control over their
system, and do not want all the features that systemd provides and
automatically activates. 

von Johannes O. (jojo_2)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Holm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nimm FreeBSD.
Poettering ist auch mein bester Freund...nur Schrott aus der Ecke.

Gruß,

Holm

von Reinhard S. (rezz)


Bewertung
0 lesenswert
nicht lesenswert
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> :)

von Georg A. (georga)


Bewertung
3 lesenswert
nicht lesenswert
> 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

von Mac G. (macgyver0815)


Bewertung
-3 lesenswert
nicht lesenswert
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 ;-)

von K. J. (theborg0815) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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:
#!/sbin/openrc-run

depend() {
  need mysql
}

start() {
  ebegin "Starting gammu-smsd"
  start-stop-daemon --start --exec "/usr/bin/gammu-smsd" --make-pidfile --background --pidfile /run/gammu-smsd.pid
  eend $?
}

stop() {
  ebegin "Stopping gammu-smsd"
  start-stop-daemon --stop --exec "/usr/bin/gammu-smsd" --pidfile /run/gammu-smsd.pid
  eend $?
}

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Holm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Michael X. (Firma: vyuxc) (der-michl)


Bewertung
1 lesenswert
nicht lesenswert
Slackware ist ohne SystemD

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> https://devuan.org/


Perfekt! Ich werde in den nächsten Wochen all meine Debian Systeme 
darauf umstellen.

von Andreas S. (andreas) (Admin) Benutzerseite Flattr this


Bewertung
4 lesenswert
nicht lesenswert
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.

von Daniel A. (daniel-a)


Bewertung
2 lesenswert
nicht lesenswert
@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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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:
#! /bin/sh
case "$1" in
  start)   start-my-daemon;;
  stop)    stop-my-daemon;;
  restart) $0 stop; sleep 1; $0 start;;
  *)       echo "usage: $0 start|stop|restart" >&2;;
esac

Wenn ich dann noch die restart-Option und die Usage-Zeile weglasse, bin 
ich auch bei 5. :-)

: Bearbeitet durch Moderator
von K. J. (theborg0815) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
von Lukey S. (lukey3332)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Guido B. (guido-b)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Holm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Daniel A. (daniel-a)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Axel S. (a-za-z0-9)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
1 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Arc N. (arc)


Bewertung
0 lesenswert
nicht lesenswert
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>

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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

von Miethai (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Markus M. (adrock)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Sven B. (scummos)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Nop (Gast)


Bewertung
5 lesenswert
nicht lesenswert
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.

von 🐧 DPA 🐧 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von mh (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
🐧 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?

von 🐧 DPA 🐧 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Mikojan Gurewitsch Trocken (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Daniel A. schrieb:
> [rant]

Was bedeutet das?

von mh (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
🐧 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.

von 🐧 DPA 🐧 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
2 lesenswert
nicht lesenswert
🐧 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.

von 🐧 DPA 🐧 (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
🐧 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?

von Mikojan Gurewitsch Trocken (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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...

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 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?

von Sven B. (scummos)


Bewertung
3 lesenswert
nicht lesenswert
🐧 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.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von 🐧 DPA 🐧 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
🐧 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?

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
🐧 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 ;)

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.
# uptime
 13:32:28 up 928 days, 19:39,  2 users,  load average: 0.15, 0.18, 0.18

(ö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.

: Bearbeitet durch Moderator
von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von mh (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von mh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von mh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
3 lesenswert
nicht lesenswert
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

von 🐧 DPA 🐧 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Gähn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von mh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
🐧 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...

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von mh (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Büchse der Pandora wurde nunmal leider wieder geöffnet...

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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..."

von Jack V. (jackv)


Bewertung
2 lesenswert
nicht lesenswert
🐧 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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Jack V. (jackv)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von mh (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Die Büchse der Pandora wurde nunmal leider wieder geöffnet...

Behälst du dir das alleinige Recht vor, diese Büchse zu öffnen?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Jack V. (jackv)


Bewertung
-1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.