keine inittab - wie runlevel konfigurieren

[Kermit24]

Wohl oder viel mehr übel muss ich mich jetzt zwangsweise mit dem neuen debian anfreunden. Gibt es wenigstens gute, deutsche Anleitungen? Im Thread "Bitte lesen: Einstieg in Debian" bin ich nicht fündig geworden. Debian Anwenderhandbuch wurde offenbar auch nicht aktualisiert und im wiki finde ich in Deutsch auch nicht sehr viel.
Mein gekauftes Debian Anwenderhandbuch und meinen alten Kofler kann jetzt wohl auch ins Altpapier wandern

Ich stehe nun vor der ersten Hürde, die Runlevel anzupassen. Bisher waren das immer 5 Minuten Anpassen der inittab und rc-confs. Doch hier stehe ich gerade völlig auf dem Schlauch.
Ich hätte gerne, fast wie üblich (verstehe nicht, warum nur debian das nicht von vornherein richtig mitbringt)
Runlevel 1: nur root, 1 getty (tty1), nur das nötigste (keine serverdienste)
Runlevel 2-4: 5 gettys (tty1-5), alle daemons, nur textconsole - defaultrunlevel nach boot
Runlevel 5: wie 2-4 + Grafiksession auf tty7
Immerhin funktionieren zumindest Runlevel 0+6 noch wie gewohnt.

tty6 lasse ich immer frei für die Kernelmeldungen (setlogcons 6)


Gibt es eine gute, möglichst deutsche Anleitung, wie man in einem aktuellen debian die runlevel hinbekommt?

Danke im Voraus.

[MSfree]

Gibt es eine gute, möglichst deutsche Anleitung, wie man in einem aktuellen debian die runlevel hinbekommt?

Es gibt keine Runlevels mehr. SysVInit wurde mit Debian 8 ca. 2014/2015 durch systemd abgelöst.

[Kermit24]

Äh, doch: who -r -> Runlevel 5 2019-04-12 11:00 -> init 3 -> who -r Runlevel 3

[JTH]

systemd hat als Ersatz für Runlevel sogenannte Targets, die eine bestimmte Auswahl an Diensten und co. starten:

Runlevel 1: nur root, 1 getty (tty1), nur das nötigste (keine serverdienste)

Entspricht ungefähr rescue.target.

Runlevel 2-4: 5 gettys (tty1-5), alle daemons, nur textconsole - defaultrunlevel nach boot

Entspricht ungefähr multi-user.target.

Runlevel 5: wie 2-4 + Grafiksession auf tty7

Entspricht ungefähr graphical.target.

Um zu einem „Runlevel“ zu wechseln:

Code: Alles auswählen

# systemctl isolate multi-user.target

Runlevel 2-4: 5 gettys (tty1-5), alle daemons, nur textconsole - defaultrunlevel nach boot

Um den Default nach dem Booten zu setzen:

Code: Alles auswählen

# systemctl set-default multi-user.target

Wenn du das tatsächlich so kleinteilig einreichten willst, lässt sich auch anpassen, welche Dienste die Targets jeweils starten. Das ist allerdings etwas Tipparbeit, lässt sich nicht in einer Datei festlegen.

Zum ersten Nachschauen, welche Dienste von einem Target jeweils gestartet werden:

Code: Alles auswählen

$ systemctl list-dependencies multi-user.target

[Kermit24]

Vielen Dank für die Mühe JTH, dass Du mir das alles so beschreibst. Das wäre aber wirklich nicht nötig. Es muss doch irgendwo eine anständige Dokumentation dazu geben ? Nach mehreren Jahren Systemd kann ich mir nicht vorstellen, dass es kein einführendes, verständliches, deutsches Tutorial, am liebsten als gedrucktes Buch, gibt?
Ich möchte die Prozesse gerne verstehen, wenn ich demnächst täglich damit arbeite.

[Apfelmann]

https://wiki.archlinux.de/title/Systemd

LG

[irianx]

zufällig gefunden ... wieder was gelernt ... danke für den link

[Kermit24]

Zwar spät, aber ich bin an systemd immer noch am Verzweifeln: Im verlinkten arch-linux wiki stehen auch nur die basis kommandos.

Ich nutze jetzt ein halbes Jahr buster mit systemd und fühle mich immer noch wie ein Windows-User, der keinen Plan davon hat, was hier überhaupt abgeht
Einfache Anleitungen für den Einstieg sind nicht zu finden. Ich weiß nicht, was passiert ist, aber nach Neustart meines Rechners (kommt selten vor), sind jetzt alle gettys weg. Ich komme sofort zum grafik-login auf tty7. Dieser funktioniert glücklicherweise noch. Im xterm kann ich also noch arbeiten. Auf tty1 sehe ich nur Meldungen und auf den anderen nur noch blinkende cursor. isc-dhcpd bringt eine Fehlermeldung (laut status hängt es mit ipv6 zusammen), was aber hoffentlich nicht der Grund sein kann, dass meine Text-Konsolen alle weg sind.

Es ist ja schön, dass man Target wechseln und anzeigen kann. Aber ich wüsste gerne mal, in welchen target ich mich momentan überhaupt befinde?
NACHTRAG: Ich sollte im default target landen, den ich so erfahre:
systemctl get-default
graphical.target


Wo finde ich die services für die Text-Konsolen? Unter /etc/systemd finde ich nur ein Symlink /etc/systemd/system/getty.target.wants/getty@tty1.service der auf /lib/systemd/system/getty@.service zeigt. Keine Ahnung wie das gestartet werden soll
Probiere ich ein "systemctl start getty@tty1.service", so bleibt der Befehl einfach hängen.
Ein einfach debug-Möglichkeit, wie bei einem init-script (sh -x / set -x) kenne ich für die systemd services auch noch nicht. Ich bin von durch die bestehende Intransparenz noch völlig aufgeschmissen.

NACHTRAG: Im englischen arch-linux wiki findet sich deutlich mehr: https://wiki.archlinux.org/index.php/Systemd
traurig nur, dass man als debian-user auf arch-linux docs zurückgreifen muss.
auf freedesktop.org finde ich auch noch reichlich doku: https://www.freedesktop.org/wiki/Software/systemd/
NACHTRAG2: letzter Link führt zu einer debian-doku: https://wiki.debian.org/systemd

[TomL]

Aber ich wüsste gerne mal, in welchen target ich mich momentan überhaupt befinde?

Eigentlich muss man das in dieser scheinbar beabsichtigten Intention gar nicht wissen. Das Vorgehen von systemd beim Systemstart ist völlig anders, als man das von den früheren Runlevels erwarten konnte. systemd versucht nämlich mehr oder weniger alles gleichzeitig zu starten, nicht seriell nacheinander, wie sysvinit das früher getan hat.

Die Targets definieren nach meinem Verständnis nur einen Zeitpunkt, wann bestimmte Services (auch eigene) gestartet sein müssen. Um die erfüllte Abhängigkeiten meiner eigenen Jobs (via Service-Units) innerhalb eines Targets muss ich mich selber kümmern. Also wenn mein Service auf Netzwerkressourcen zugreifen muss, startet systemd meinen Service durchaus auch bevor das Netzwerk gestartet wird und killt meinen Prozess wieder, wenn der sich nicht in der vorgebenen Timeout-Zeit als erfolgreich abgeschlossen bei systemd meldet. Also muss ich meinen Service so in den Targets positionieren und zusätzlich die Abhängigkeiten mit After-, Before- oder Requires-Statements bezogen auf andere Service-Units eindeutig definieren, damit systemd meinen Job so in den Start einreiht, dass er trotz parallelen Starts erfolgreich ist.

Schau Dir einfach mal mit einem Picture-Viewer den Plot des Bootprozesses Deines Rechners an:

Code: Alles auswählen

systemd-analyze plot >~/bootplot.svg
systemd-analyze critical-chain 

Edit:
Und um auf die Frage zurückzukommen... wenn ich in der Install-Sektion meiner Service-Unit "WantedBy=multi-user.target" weiss ich doch, wann mein Service gestartet ist... und zwar wenn dieses Target 'durch' ist.

[Kermit24]

Danke!
systemd-analyze zeigte mir an:

Code: Alles auswählen

 Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs

Im systemctl list-jobs konnte ich erkennen, dass rc.local hing "rc-local.service start running"
Und zwar hatte ich wegen DSL-Verbindungsproblemen den pppd vor einiger Zeit auf "nodetach" gesetzt und in einem terminal damit im Vordergrund am Mitlaufen gehabt. Mein connect-script rufe ich über die /etc/rc.local auf. Seltsam, dass die Text-Konsolen alle erst danach kommen, aber die Grafikoberfläche schon vorher.

[TomL]

Ja, dann hängt anscheinend schon einer der Jobs.... vermutlich ein Konfigurationsfehler einer eigenen Unit. Kann man das nicht im Plot erkennen? Ich muss auch sagen, dass ich das mit Deinen TTY's gar nicht verstehe. Hier sind die alle automatisch gestartet, ich kann mit AltGr+[1-6] jedes TTY öffnen und bekomme eine Shell. Also manuell muss ich mit einem Standard-Debian da gar nix an irgendwelchen Service-Units rumschrauben, das geht einfach.

rc-local ist auch obsolet... auch wenn das im Kompatibilitätsmodus mit einer autogenerierten Service-Unit zu einem doch eher zufälligen Zeitpunkt noch irgendwie geht. Statt rc-local ist eine eigene Unit der bessere Weg.

[JTH]

Seltsam, dass die Text-Konsolen alle erst danach kommen, aber die Grafikoberfläche schon vorher.

Das ist explizit so festgelegt. Der getty@.service, der die Vorlage für die TTYs 1–x ist (nennt sich dann getty@tty1.service, getty@tty2.service etc.), wird ausdrücklich erst gestartet, nachdem rc.local durchgelaufen ist:

Code: Alles auswählen

$ systemctl cat getty@.service
[…]

[Unit]
After=rc-local.service

[…]

Du müsstest also mal schauen, dass dein rc.local nicht endlos hängt oder es durch einen Systemd-Service ersetzen. In letzterem kann dann auch ohne Probleme ein Skript aufgerufen, dass mit Ausgaben und im Vordergrund endlos läuft.

[guennid]

Auch buster geht, ebenso wie stretch nach wie vor auch ohne systemd (mit gnome natürlich nicht. Und einige Dateimanager im XFCE-Umfeld verlangen es direkt oder indirekt ebenfalls - ist halt kein init-System, sondern ein System-Daemon).

Grüße, Günther