mikrocontroller.net

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


Autor: Daniel Abrecht (daniel-a)
Datum:
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
Autor: Georg A. (georga)
Datum:

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.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

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,_a...
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. 

Autor: Johannes O. (jojo_2)
Datum:

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.

Autor: Holm Tiffe (holm)
Datum:

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

Gruß,

Holm

Autor: Reinhard S. (rezz)
Datum:

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> :)

Autor: Georg A. (georga)
Datum:

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

Autor: Mac Gyver (macgyver0815)
Datum:

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 ;-)

Autor: K. J. (theborg0815) Benutzerseite
Datum:

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 $?
}

Autor: Georg A. (georga)
Datum:

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.

Autor: A. K. (prx)
Datum:

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.

Autor: Holm Tiffe (holm)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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
Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Slackware ist ohne SystemD

Autor: Daniel Abrecht (daniel-a)
Datum:

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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

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.

Autor: Daniel Abrecht (daniel-a)
Datum:

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.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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
Autor: K. J. (theborg0815) Benutzerseite
Datum:

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
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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
Autor: Lukey S. (lukey3332)
Datum:

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

Autor: Axel Schwenke (a-za-z0-9)
Datum:

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.

Autor: Gerd E. (robberknight)
Datum:

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.

Autor: Guido B. (guido-b)
Datum:

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!

Autor: Georg A. (georga)
Datum:

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.

Autor: Holm Tiffe (holm)
Datum:

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

Autor: Daniel Abrecht (daniel-a)
Datum:

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.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

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!

Autor: Axel Schwenke (a-za-z0-9)
Datum:

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.

Autor: Gerd E. (robberknight)
Datum:

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.

Autor: A. K. (prx)
Datum:

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
Autor: Arc Net (arc)
Datum:

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

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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