nevatar
Hi,
ich liebte Arch, weil es meiner KISS-Philosophie ziemlich nahe kam ... bis zu dem Zeitpunkt, als systemd eingeführt wurde, der Anti-KISS-Daemon schlechthin.
systemd tut alles und das schnell, aber hinter verschlossenen Türen ... bei Problemen ist man schlechterdings aufgeschmissen. Aktuelles Beispiel: Ich wollte arch auf einer SD-Karte für mein altes netbook-Schätzchen installieren, die SD-Karte wollte ich mit f2fs formatieren, funktionierte auch alles wunderbar, Installation via pacstrap innerhalb kürzester Zeit erledigt, booten klappte auch perfekt und
dann kam systemd, besser gesagt journald, der irgendwie während des Bootprozesses hing und zwar nicht wirklich, er quälte sich durch alle Bootschritte, jeder einzelne meldete nach ca. 2 Minuten einen jounald timeout ... das ganze 2 mal ausprobiert weil ich dachte, ich hätte etwas falsch gemacht, danach die ganze Prozedur mit ext4 und siehe da, alles funktioniert. Nur wie analysiert man das Problem, wenn der Bootvorgang ca. 30 Minuten dauert, es keine Abkürzung gibt, das Journal nicht geschrieben wird und alles rund um systemd irgendwie hängt ?
Lustigerweise habe ich während der ganzen Prozedur mal einen Fehler gemacht und das root device während des gesamten Bootvorgangs auf read-only gehabt und siehe da, alles bootete wunderbar, nur leider half mir das auch nicht weiter, da sich das rootdevice später nicht mehr schreibbar remounten liess.
Irgendwie scheinen sich f2fs und systemd nicht zu vertragen (beim schreiben, Lesen geht super) ... da systemd aber inzwischen so stark verzahnt mit arch ist, funktioniert das ganze System nicht mehr.
Bisher war der arch Grundgedanke ja ... hey, wenn mir das nicht gefällt, nehm ich halt was anderes, nur beim Bootprozeß gibt es kein Wahl mehr, nimm systemd oder such dir halt ne andere Distribution (ja, welchen denn .... es scheinen alle auf die paar Sekunden, die systemd schneller bootet als die old-fashioned sysv init Skripte abzufahren).
Systemd mag vielen Leuten die Arbeit erleichtern oder ihr System schneller machen ... für mich persönlich hat systemd nur Nachteile und ich will es loswerden, geht das mit arch oder muss ich mir was neues suchen ?
bye,
N.
[gelöscht]
https://wiki.archlinux.org/index.php/Openrc
Das nächste mal erst informieren, dann rumheulen.
nevatar
Danke für den Tipp ... habe ich trotz seehr langem rumgoogeln und suchen in den einschlägigen Foren
nicht gefunden.
bye,
N.
PS: Ich bleibe dabei, systemd ist die Pest ... ich hab's lange versucht und alle möglichen freezes und dbus unverträglichkeiten ausgehalten und mir immer wieder gesagt, ich sei zu dumm dazu ... arch ist immer noch eine wunderbare distri, sehr modular, schlank, super zu installieren ... nur leider stehe ich im Regen, wenn es zu Schwierigkeiten kommt.
[gelöscht]
Ein Problem scheint das logging von systemd zu sein. Du kannst systemd das logging abgewöhnen (Bestimmt! irgendwie…). Auf jeden Fall könntest du das Logging an einen weiteren Logger weiterreichen der es nach /Platte schiebt damit du ein nicht binäres Log zum Lesen hast. Vielleicht ist auch das Dateisystem einfach nicht in der Lage so schnell zu schreiben. Vielleicht reicht es wenn du /var/log/ mit einem anderen Dateisystem betreibst.
Und die initiale Frage beantwortend: Nein.
[gelöscht]
> (Bestimmt! irgendwie…).
Manpages lesen, Kruzitürken nochamol.
> Und die initiale Frage beantwortend: Nein.
Doch.
[gelöscht]
Oh, in besagten Manpages steht auch, wie man das Journal so einstellen kann, dass es nicht auf die Festplatte schreibt.
Aber Manpages sind ja nicht KISS, nicht der Unix-Weg und eine bösartige, userfeindliche Erfindung von Lennart…
[gelöscht]
No'op schrieb> (Bestimmt! irgendwie…).
Manpages lesen, Kruzitürken nochamol.
Und aus den manpages habe ich gelesen das systemd-journald logt, ob du willst oder nicht. Man kann, soweit ich das recheriert habe lediglich das persistente loggen nach /var/log/journal unterbinden. Falls du da anderes gefunden hast dann schreib bitte in welcher manpage und in welchem Abschnitt.
No'op schrieb> Und die initiale Frage beantwortend: Nein.
Doch.
Bestimmt nicht.
[gelöscht]
> Und aus den manpages habe ich gelesen das systemd-journald logt, ob du willst oder nicht.
JOURNALD.CONF(5) schrieb Storage=
Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile",
journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is
created if needed). If "persistent", data will be stored preferably on disk, i.e. below the
/var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is
created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent"
but the directory /var/log/journal is not created if needed, so that its existence controls where log data
goes. "none" turns off all storage, all log data received will be dropped. Forwarding to other targets,
such as the console, the kernel log buffer or a syslog daemon will still work however. Defaults to "auto".
[…]
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog
daemon, to the kernel log buffer (kmsg), or to the system console. These options take boolean arguments.
If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect.
By default, only forwarding to syslog is enabled. These settings may be overridden at boot time with the
kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=" and
"systemd.journald.forward_to_console=".
Lesekompetenz ist echt schwer. 🙂
> Bestimmt nicht.
O RLY?
nevatar
Hi,
tatsächlich steht in der manpage von systemd folgendes:
--log-target=
Set log target. Argument must be one of console, journal, syslog,
kmsg, journal-or-kmsg, syslog-or-kmsg, null.
Das müsste man mal ausprobieren, das könnte das log-Problem beseitigen, hilft mir aber immer noch nicht bei diversen dbus-Problemen, die ich in der Vergangenheit hatte .... zur Ehrenrettung muss man dazusagen, das dieses "Anfangsschwierigkeiten" wohl inzwischen gefixt sind, eine frische Neuinstallation läuft inzwischen ohne nennenswerte Probleme.
Mein Eindruck vom System mit systemd ist einfach so ... das man bei Problemen einfach hilflos bis zum Erscheinen einer neuen Version (eines neuen Kernels, etc.) dasteht ... vorher konnte ich mir zumindest meist durch ein-/auschalten von Diensten, etc weiterhelfen oder wenigstens ein "Rumpfsystem" zum laufen bringen, daran bin ich in der jüngeren Vergangenheit mehrfach gescheitert und es lag immer am systemd (bzw. dessen Abhängigkeiten) ... wenn es dann einmal läuft, ist es auch gut und stabil, da möchte ich ja nicht meckern.
bye,
N.
Smon
No'op schriebAber Manpages sind [...] eine bösartige, userfeindliche Erfindung von Lennart…
Ich mag dich!
nevatar schrieb tatsächlich steht in der manpage von systemd folgendes:
Nevatar: Es geht um die Manpage von journald.conf
$ man journald.conf
Hier steht es gleich zu Beginn.
nevatar schriebeine frische Neuinstallation läuft inzwischen ohne nennenswerte Probleme.
Kennst du *.pacnew Dateien?
Ich hatte bisher noch keine großen Probleme mit systemd, an welche ich mich noch erinnere.
[gelöscht]
No'op schriebAber Manpages sind [...] eine bösartige, userfeindliche Erfindung von Lennart…
Ich hatte bisher die Erfahrung gemacht das es andersrum ist: Lennart Poettering ist ein böseartige manpagefeindliche Erfindung der User.
No'op schrieb> Und aus den manpages habe ich gelesen das systemd-journald logt, ob du willst oder nicht.
JOURNALD.CONF(5) schrieb Storage=
Lesekompetenz ist echt schwer. 🙂
Herrlich! Das sind diese Momente, ich muss dann immer noch einmal genau schauen ob ich nicht vielleicht doch im Heise-Forum bin. Ich wiederhole es so gern nochmal:
No'op schriebLesekompetenz ist echt schwer. 🙂
*fcplm
Na gut, wenn du meine Lesekompetenz in Zweifel ziehen magst, dann wirst du mir nicht übel nehmen wenn ich selbiges mit deiner tue. Damit es dir leichter fällt hebe ich die relevanten Passagen hervor.
JOURNALD.CONF(5) schrieb Storage=
Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile",
journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is
created if needed). If "persistent", data will be stored preferably on disk, i.e. below the
/var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is
created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent"
but the directory /var/log/journal is not created if needed, so that its existence controls where log data
goes. "none" turns off all storage, all log data received will be dropped. Forwarding to other targets,
such as the console, the kernel log buffer or a syslog daemon will still work however. Defaults to "auto".
[…]
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog
daemon, to the kernel log buffer (kmsg), or to the system console. These options take boolean arguments.[…]
Dort irgendwie nur wie systemd-journald mit den Daten die durch diesen Dienst empfangen werden weiter verfährt. Und wenn ich mir dann anschaue welche Abhängigkeiten zum Start von systemd-journald.service führen, dann mag ich nicht darin rumpfuschen (obwohl es eigentlich möglich sein sollte, weils ja so modular und flexible ist).
Ich schließe daraus: Der Dienst läuft. Und er empfängt Daten und tut etwas damit (speichern und weiterleiten | nicht speichern und weiterleiten | flüchtig speichern und weiterleiten). Solange du diesen Dienst nicht am Start hinderst kannst du wohl nicht verhindern das er logt.
No'op schrieb
> Bestimmt nicht.
O RLY?
Mir scheint wir haben eine unterschiedliche Auffassung von der initialen Frage.
[gelöscht]
> Ich schließe daraus: Der Dienst läuft.
No shit, Sherlock! War nur nie die Frage.
> Und er empfängt Daten und tut etwas damit
Er loggt sie nicht. Er leitet sie weiter. So wie eine Pipe. Wenn du IPC-Mechanismen als Logging-Dæmons definieren willst, kann ich dir auch nicht weiterhelfen.
> obwohl es eigentlich möglich sein sollte, weils ja so modular und flexible ist
Dann ersetz doch mal klogd in Archs sysvinit (oder wie der Early-Boot-Logging-Dæmon hieß). Das geht ja SO viel einfacher, weil du dich dafür nur durch 1500 Zeilen Basherbrochenes kämpfen musst…
Die API ist öffentlich dokumentiert, es hindert dich niemand daran, sd-journal in einem Syslog-Dæmon zu implementieren.
nevatar
Hi Leute,
bevor ihr euch hier zerfleischt :-) ... meine ursprüngliche Frage wurde beantwortet, es ist jetzt müssig, darüber zu diskutieren, ob man
die systemd-Komponenten ganz weg bekommt, das ist auch so von den Kern-Arch-Entwicklern nicht gewollt, in dem Forumthread zu dem openrc-Thema geht's auch ziemlich heftig ab, das scheint ein ziemlicher Aufreger zu sein ... ähnlich wie "vi vs. emacs" (annodazumal) oder "GNOME vs KDE", hier haben halt die Maintainer entschieden, auf systemd zu setzen, was deren gutes Recht ist,
ich muss damit leben, kann das auch ... aber ich muss systemd nicht mögen und darf auch nach Alternativen suchen :-).
Ich werde openrc auf jeden Fall mal ausprobieren ... da ich keine Desktop-Umgebung wie GNOME oder KDE verwende, sollte das ohne weiteres möglich sein. Die ganzen schönen Dinge, die systemd mir bietet, nutze ich ja gar nicht :-)
bye,N.
[gelöscht]
Viel Spaß. 🙂
Dirk
nevatar schriebsystemd tut alles und das schnell, aber hinter verschlossenen Türen ...
Das ist schlicht falsch bis gelogen (das Gentoo-Wiki hat zum Thema "Lügen über systemd" einige Beispiele). Systemd ist gut dokumentiert, und für interessierte mindestens genau so gut nachvollziehbar. Es funktioniert eben einfach nur komplett anders als SysVinit und dessen "Derivate". Um bei deiner Analogie zu bleiben: Ja, die Türen mögen verschlossen sein, aber der Schlüssel liegt unter der Fußmatte, du must ihn dir nur nehmen.
nevatar schriebIrgendwie scheinen sich f2fs und systemd nicht zu vertragen (beim schreiben, Lesen geht super)
Ich gehe davon aus, dass du das reproduzierbar mit unterschiedlicher Hardware wiederholen kannst, und einen Bugreport geschrieben hast. Ansonsten hast du in deiner Aussage zwischen "systemd" und "nicht" ein "bei mir" vergessen 🙂
nevatar schriebfür mich persönlich hat systemd nur Nachteile und ich will es loswerden, geht das mit arch oder muss ich mir was neues suchen ?
Langfristig wirst du um systemd nicht herumkommen, da immer mehr Distributionen darauf umsteigen (bzw. es schon lange sind. Arch ist tatsächlich von den "aktuellen Distributionen" eine von den späteren, die umgestiegen sind), und es durch die Bank weg SysVinit ablösen wird. Du kansnt ja zu Gentoo (nutzt ein "SysVinit auf Crack") oder Ubuntu (die kochen eh überall ihr eigenes Süppchen) wechseln, die werden wohl auch weiterhin kein oder kaum systemd nutzen.
Ovion
@No'op:
Funktioniert OpenRC denn auch in Arch? So wie ich das weiß, ist OpenRC ein sysVinit-enhanced, das heißt, es braucht Initskripte, die in Arch nicht geshippt werden. Funktioniert OperRC also auch vernünftig oder ist das eher ein Proof-of-Concept?
Dirk
Ovion schriebFunktioniert OperRC also auch vernünftig oder ist das eher ein Proof-of-Concept?
Deine Config-Scripte musst du dir natürlich selbst schreiben. Alles != systemd ist in Arch nicht "verpflichtend". Wobei, vielleicht liefert das ja irgendwie für die gängigsten Programme entsprechende Scripte mit.
Ovion
Dachte ich mir. Damit eher Proof-of-Concept, wenn man für jeden Daemon ein eigenes Skript schreiben muss.
Wobei sich doch aus den Units relativ einfach Standardkkripte generieren lassen müssten, oder? Unitfile -> Shellscript sollte nicht so schwierig sein, oder muss man viel systemd-Logik in die Skripte mit reinschaufeln?
portix
Es gibt auch noch ignite, das ist ein auf Arch angepasstes runit. Das braucht zwar auch init Skripte, die sind aber deutlich einfacher zu schreiben als Skripte für SysVinit. Zudem bootet runit auch deutlich schneller als SysVinit weil es daemons parallel starten kann.
Zudem gibt es auch noch busybox-runit wenn man es minimalistischer haben will.
Dirk
Ovion schrieb... oder muss man viel systemd-Logik in die Skripte mit reinschaufeln?
start, stop, restart, status, und was es da sonst noch alles gibt.