staging.inyokaproject.org

Da Utopic mit systemd starten wird (oder soll), eröffne ich diesen Artikel. Da mein Debian Testing vor kurzer Zeit auf systemd gewechselt hat sammle ich im Wikiartikel Baustelle/systemd mal die Schwierigkeiten, die mir auffallen. Die Chance ist ja nicht so klein, dass in Utopic die selben Probleme auftauchen werden. 😀

Sehr vorausschauend 👍

So spotan würde ich schonmal sagen, dass der Hinweis zur Reaktivierung der rc.local als Dienst später direkt in den zugehörigen Wiki-Artikel sollte. Wenn verschiedene Befehle in der Datei stehen, die unterschiedliche Types voraussetzen, erscheint mir es mir aber eh nicht mehr sinnvoll, die rc.local unter systemd überhaupt weiter zu empfehlen. Das Erstellen eigener Dienste ist mit brauchbarer Dokumentation ziemlich einfach, wenn auch zugegebener Maßen nicht mehr so schön zu beschreiben wie mit einem:

echo "COMMAND" | sudo tee -a /etc/rc.local 

So, mein Senf abgegeben und Thema damit in meinem Verlauf für die Zukunft markiert 😀

Stand der Dinge? Reif für's Wiki? Gruss

frustschieber schrieb:

Stand der Dinge? Reif für's Wiki?

Na, da fehlt schon noch ein wenig; zumindest in die zwei Gelben muss Rudimentäres rein. Ich weiß aber nicht wann ich dazu komme, ist ziemlich was los hier, und das wird auch noch geraume Zeit andauern.

So! Ein wenig ergänzt. Es sollte dringend jemand drüber schauen, denn ich bin bei systemd blutiger Anfänger. ☺

pepre schrieb:

So! Ein wenig ergänzt. Es sollte dringend jemand drüber schauen, denn ich bin bei systemd blutiger Anfänger. ☺

Hab den Artikel etwas angepasst, die Tage komme ich hoffentlich noch dazu etwas mehr zu schreiben.

Units sollte man in einen eigenen Artikel auslagern, das gleiche gilt für journald. Hintergrund ist das diese beiden Themen recht komplex sind, daher wären das am besten Unterseiten und systemd nur eine Übersichtsseite mit den wichtigsten Dingen.

mfg Stefan Betz

Units sollte man in einen eigenen Artikel auslagern, das gleiche gilt für journald.

Klar. Meine Intention war: kurz und knapp die wichtigsten Befehle und Mechanismen darstellen, - als schnelle Nachschlaghilfe sozusagen. Innerhalb dieser kann man dann die Unterartikel einpflegen, die das Geschehen en Detail erklären. Sonst muss man immer mit drei (oder mehr) Artikeln hantieren, obwohl man nur kurz mal die "Wie ging das wieder?"-Frage hat. Zumindest mir geht es mit systemd so; und ich denke, ich bin da nicht der Einzige.

Und ich wollte nicht jetzt schon das Faß mit den Unterartikeln aufmachen. Motto: wachsen lassen, bis sich eine Auslagerung lohnt.

Weil ich das gerade sehe:

Die Datei /etc/rc.local wird von systemd nicht mehr ausgewertet. Man kann systemd aber so erweitern, dass es das trotzdem tut […]

Das würde ich rausschmeißen, da man rc.local durch entsprechende Service-Units ersetzen sollte (würde ich auch so schreiben).

Developer92 schrieb:

Das würde ich rausschmeißen, da man rc.local durch entsprechende Service-Units ersetzen sollte (würde ich auch so schreiben).

Das würde ich drin lassen, damit man beim dist-upgrade keine bösen Überraschungen erlebt, weil plötzlich die rc.local nicht mehr bedient wird.

Natürlich kann man dann auf den zukünftigen Unit-Artikel verweisen, indem erklärt wird, wie man so was selbst schreibt. Wobei ich das als gehüpft wie gesprungen ansehe: ob die Datei nun /etc/rc.local heisst, oder als /usr/local/bin/blablubb (oder als /etc/systemd/system/whatever) auftritt, ist an und für sich schnurz.

pepre schrieb:

Das würde ich drin lassen, damit man beim dist-upgrade keine bösen Überraschungen erlebt, weil plötzlich die rc.local nicht mehr bedient wird.

Allerdings ist das dann ein ganz schlechter Stil. Natürlich könnte man mit systemd die rc.local weiterhin verwenden oder auch SysVInit auf Basis von systemd nachbauen - macht allerdings keinen Sinn. Dafür gibt es Units.

Natürlich kann man dann auf den zukünftigen Unit-Artikel verweisen, indem erklärt wird, wie man so was selbst schreibt. Wobei ich das als gehüpft wie gesprungen ansehe: ob die Datei nun /etc/rc.local heisst, oder als /usr/local/bin/blablubb (oder als /etc/systemd/system/whatever) auftritt, ist an und für sich schnurz.

Nicht wirklich. In rc.local kann man bzw. hat man gerne mal mehrere, von einander unabhängige, Dinge stehen. Mit den Units trennt man diese sauber voneinander (auch für Fehleranalayse und dergleichen wesentlich geeigneter).

Hallo,

wie ist denn hier so konkret der Plan für's Wiki? Wie oben gesagt kann man zu dem Thema sicherlich noch (viel) mehr schreiben - oder auch eine endlose Geschichte draus machen.

IMHO ist der Artikel so ok für's Wiki. Basisinfos drin, in sich konsisitent. Wenn noch jemand bestätigt, dass der Inhalt stimmt, wäre es IMHO sinnvoll, den Artikel zu schieben und danach an den Artikeln zu Units und journalctl zu schreiben.

Gruß, noisefloor

Developer92 schrieb:

Allerdings ist das dann ein ganz schlechter Stil.

Ja. Und nein. 😀 Ich glaube, wir reden sauber aneinander vorbei.

Es geht doch darum, dass Menschen, die $wasauchimmer in der rc.local stehen haben, nach einem dist-upgrade feststellen müssen, dass ihr $wasauchimmer nicht ausgeführt wird. Ging ja bisher auch immer, und hat alle Upgrades schadlos überstanden. Das kann also überhaupt nicht auf dem Radar sein (ich bin ja auch erstmal überrascht worden). - Wir brauchen also sowas:

Anschliessend kann man dann - per Link in den Unit-Artikel - Details zur politisch korrekten und moralisch einwandfreien Umsetzung machen. Ok so?

Wie ich persönlich das Ganze betrachte, bewerte und realisiere spielt dabei keine Rolle.

pepre schrieb:

Ja. Und nein. 😀 Ich glaube, wir reden sauber aneinander vorbei.

Das wird mir jetzt auch klar. Wenn der Artikel zu den Units steht (Freiwillige vor) sollten wir das so wie du sagst verlinken.

Ein paar Anmerkungen:

• --no-pager ist bei journalctl nicht erforderlich, es erkennt automatisch ob das Terminal oder eine Pipe für stdout zuständig ist.

• sudo systemadm, startet man grafische Programme nicht eher mit gksudo & Co?

• disable verhindert nicht den Start eines Unit, sondern erreicht nur das es nicht direkt gestartet wird. Andere Units könnten es als Abhängigkeit haben und es daher trotzdem Starten.

• reload lädt die Konfiguration des Dienstes, nicht des Units neu. Units werden mit daemon-reload neu geladen.

• journalctl -f -u unit entspricht einem tail -f /var/log/dienstname

mfg Stefan Betz