suckless init (sinit) mit stretch?

[RobertDebiannutzer]

In diesem Thread schildere ich meine Erfahrungen beim Einsatz eines anderen Init-Systemes in stretch.
Bisher habe ich immer sysvinit genommen, weil das eine der beiden Abhängigkeiten von init ist.

Nun aber überlege ich immer mehr, auch mal sinit, das init des suckless-Projekts, auszuprobieren. Der Link zur Projektseite: https://core.suckless.org/sinit und die git-Seite: https://git.suckless.org/sinit/

So wie ich den Code verstehe, läuft das so, dass sinit das Starten und Beenden der Dienste an die in config.def.h gelisteten Programme weitergibt:

Code: Alles auswählen

/* See LICENSE file for copyright and license details. */

static char *const rcinitcmd[]     = { "/bin/rc.init", NULL };
static char *const rcrebootcmd[]   = { "/bin/rc.shutdown", "reboot", NULL };
static char *const rcpoweroffcmd[] = { "/bin/rc.shutdown", "poweroff", NULL };

D.h., man könnte einfach an diese Stellen entsprechende shell-scripte hinterlegen, oder?
Diese könnten dann vielleicht in etwa so aussehen (zu den entsprechenden runlevel-Nummern siehe "man init"*)?
/bin/rc.init:
1. nachschauen in Konfigurations-Datei /etc/init.conf (oder so ähnlich), in welches runlevel zu booten ist
2. alle scripte in /etc/rcS.d/ ausführen
3. alle scripte in /etc/rc"$runlevel".d/ ausführen
4. rc.local ausführen (ggf. nur unter der Bedingung, dass $runlevel ein bestimmter Wert ist)

Das Starten der getty-Prozesse könnte dann in ein entsprechendes init-Script unter /etc/init.d/, welches nach /etc/rc[1-5].d/ verlinkt würde.

/bin/rc.shutdown könnte vielleicht so aussehen?
- wenn argument=poweroff:
1. alle scripte in /etc/rc0.d/ ausführen
- wenn argument=reboot:
1. alle scripte in /etc/rc6.d/ ausführen

Was meint ihr?

*Wer nicht sysvinit-core installiert hat, hat die falsche manpage. Hier der Link zur init-manpage von sysvinit-core: https://manpages.debian.org/stretch/sys ... .8.en.html

[RobertDebiannutzer]

Ich habe jetzt mal ein bisschen gescriptet. Nun mache ich einfach ein/mehrere Probelauf/-läufe - je nachdem, wie's so klappt. Wenn ich mich in den nächsten Tagen nicht mehr melde, wisst ihr, dass ich neuinstallieren musste...

[RobertDebiannutzer]

Nix neuinstallieren:

Code: Alles auswählen

    1     0     0     0 ?        root     root     00:00:00 sinit

Ja, meine Scripte haben (mit anfänglichen Schwierigkeiten mit agetty) gut funktioniert. (Schlau ist natürlich, wenn man zum Testen mit dem Kernel-Parameter init=/sbin/sinit bootet, dann kann man leicht in Grub wieder umstellen, falls es zu Problemen kommt.)

Naja, weitere Ausführungen spar' ich mir mal, scheinbar scheint das Thema hier im Forum auf wenig Interesse zu stoßen.
Nur eines noch: In meinem ersten Beitrag schrieb ich, dass zum reboot erst alle scripte in /etc/rc0.d/ auszuführen sind und dann alle in /etc/rc6.d/. Das ist natürlich Quatsch - zum reboot werden nur die scripte in /etc/rc6.d/ ausgeführt.
Habe das oben noch korrigiert.

[schwedenmann]

Hallo

@RobertDebiannutzer

Naja, weitere Ausführungen spar' ich mir mal, scheinbar scheint das Thema hier im Forum auf wenig Interesse zu stoßen.

naja, alles außerhalb von systemd ist Spielerei und Hobbytum und weiter nichts, es hat keinerlei reale Bedeutung, im Berufsleben einen IT-Neerds sowie nicht.

mfg
schwedenmann

[MartinV]

Ich finde das sehr interessant!
Ich habe nur vorher nichts geschrieben, weil ich nichts wirklich schlaues beitragen konnte.

naja, alles außerhalb von systemd ist Spielerei und Hobbytum und weiter nichts,

Es gibt auch ein Leben ohne systemd. Betriebssysteme auch.
Im Desktop-Computerbereich ist systemd dominant, aber auf Maschinen mit weniger Ressourcen ist man mit anderen Initsystemen besser bedient.
Beispiel ist Alpine Linux, das sich für embedded systems eignet und auf OpenRC setzt.
Alpine läßt sich minimal installieren und bei Bedarf modular bis zu einem kompletten Desktop-System aufstocken.
Die Abhängigkeiten der Pakete von Alpine sind bewußt minimal gehalten. Z.B. habe ich einmal einen Mate-Desktop installiert und hatte anschließend weder Fonts noch Icons. Die konnte/mußte ich noch manuell aussuchen und nachinstallieren.

[schwedenmann]

Hallo


@MartinV

Es gibt auch ein Leben ohne systemd. Betriebssysteme auch.

Ist ja richtig, ich selbst habe eine backupserver mit Freebsd 11.1 + zfs. Ihc bezog mich bei dem Statment eigentlich auf Linux und da spielt kein-systemd als init keine Rolle, erst Recht nicht, wenn um Produktivsysteme geht, das sind wohl in erster Linie die Hauptlinuxdistris und die haben nun mal alle systemd, da kommen auch die uralt veteran-admins von devuan nicht dran vorbei, somit bleibt diese nicht-systemd initmurkserei bei Linux im Grunde ein Hobby von einigen, Bedeutung hat es nicht und ist in meinen Augen, für Linux, auch rückwärtsgewand.

mfg
schwedenmann

[RobertDebiannutzer]

Och Leute, hier geht's doch nicht um systemd vs. nicht-systemd.

[OT]
Und was rückwärtsgewandt ist und was nicht, sehen eben verschiedene verschieden. Es gibt z.B. in China die tollsten IT-Innovationen zur Vernetzung der Bürger... Wirklich sehr fortschrittlich! Und der Datenschutz in Deutschland soll ja nun auch nicht mehr wie im 19. Jahrhundert sein (oder war's das 18. Jahrhundert? auf jeden Fall mit Flugtaxi).

Aber gut, ich kann ja mal einen Thread aufmachen mit dem Titel: "Wie lange wird sich systemd noch halten?". Da werde ich dann inhaltlich nichts beitragen und mir auch keine weitere Mühe machen, sondern ich werde mich einfach hinsetzen und warten. Dann habe ich binnen eines Tages 100 Antworten, wobei ca. 50% der Antworten über eine DIN-A4-Seite lang sein werden. Da werden die "berufstätigen IT-Nerds" wieder ganze Nachmittage opfern...
[/OT]

[KBDCALLS]

Das Problem ist aber auch dabei, das einige Programme mittlerweile systemd vorausetzen. udisks2 hat mal ohne funktioniert. Und Udev gehört mittlerweile auch zu systemd

[ViNic]

Das ist doch ein interessantes Thema

Wenn man Lust verspürt etwas auszuprobieren, warum sollte man es dann nicht machen?

[MartinV]

Soweit ich sehe, sind udisks2 und udev komfortabel, aber nicht zwingend nötig.
Wenn man sie doch braucht, kann man sie mit elogind starten und/oder eudev verwenden.

Gerade die Modularität von Linux Systemen ist ein großer Wert. Und solche Experimente, wie das Initsystem zu wechseln, tragen viel zum Verständnis bei.

Einer der Links vom Anfang führt zu einer Anleitung, wie man ein Initsystem inkl. Daemons schrittweise aufbaut. Beim Überfliegen sehr interessant, vllt. arbeite ich das irgendwann mal durch: http://troubleshooters.com/linux/diy/su ... n_plop.htm

[RobertDebiannutzer]

udev wird zwar vom systemd-Projekt betreut und der Prozess heißt auch systemd-udevd, aber in Debian gibt es keine Abhängigkeiten zu systemd.

Es ist natürlich mühsam, ein anderes init-System einzusetzen als systemd, wenn dies nicht wirklich in der Distribution vorgesehen ist. Ich weiß auch nicht, wie lange ich in dieser Situation bleibe, denn ich bin kein IT-ler. D.h., ich bin ggf. auch mal auf "just work" angewiesen und kann auch nicht die Betreuung oder Entwicklung von alternativer Software vorantreiben.

Für Deine Ansicht, @schwedemann, spricht, dass es in Debian niemanden gibt, der z.B. sysvinit-core oder systemd-shim betreuen möchte:
In https://tracker.debian.org/pkg/sysvinit steht: "RFA: The maintainer is looking for someone adopt this package."
In https://tracker.debian.org/pkg/systemd-shim steht: "O: This package has been orphaned and needs a maintainer."

Gegen @schwedemanns Ansicht sprechen mehrere Projekte, die Alternativen anbieten wollen - z.B. das bereits angesprochene Devuan:
https://www.theregister.co.uk/2018/05/1 ... candidate/
- oder anhaltende Diskussionen, auch im professionellen Umfeld:
https://www.theregister.co.uk/2018/05/1 ... t_systemd/
(beides Artikel, die ich heute zufällig gelesen habe)

[KBDCALLS]

Anscheinend wird systemd-shim auch nicht wirklich gebraucht. Danach 832508 hat der Upstream genannt Allison auch kein Bock mehr. Und Devuan verzichtet auch auf die Krücke, und kompiliert so das systemd nicht benötigt wird.

[Tintom]

Ich finde das sehr interessant!
Ich habe nur vorher nichts geschrieben, weil ich nichts wirklich schlaues beitragen konnte.

Dito, lese interessiert mit. Generell lese ich gefühlt 90 Beiträge bevor ich mal einen selbst schreibe. So geht es einigen anderen hier sicher auch.

[RobertDebiannutzer]

@KBDCALLS: Doch, AFAIK wird systemd-shim schon gebraucht, nämlich immer dann, wenn man ein anderes init-system einsetzen möchte, aber dennoch systemd als service-manager beibehalten möchte (also wenn man z.B. auf systemd-logind nicht verzichten möchte).
Devuan umgeht das, indem es systemd vollständig aus allen Paketen entfernt und für systemd-logind z.B. eine alleinstehende Alternative anbietet. Da müssen die Devuan-Leute aber - so wie ich es verstanden habe - nicht nur anders kompilieren, sondern auch Code verändern oder alternative Programme in das Ökosystem einfügen. Deswegen hat es ja auch mit ASCII länger gedauert.

Schön, dass das Thema doch den einen oder anderen interessiert.

[breakthewall]

Das Problem ist aber auch dabei, das einige Programme mittlerweile systemd vorausetzen. udisks2 hat mal ohne funktioniert. Und Udev gehört mittlerweile auch zu systemd

Die eigentliche Frage ist doch, ob man das wirklich als Problem bezeichnen kann. Denn letztlich ist Systemd ja mehr als nur ein einfaches Init-System, und soll gewissermaßen auch ein heterogenes Umfeld schaffen. Also werden qualitativ gute Komponenten miteinander verzahnt, um die Interprozesskommunikation sauberer und vor allem sicherer zu gestalten, wodurch Altes natürlich ausgesondert wird, anstatt das von qualitativ sehr flexiblen Shellscripten erledigen zu lassen, die früher so ziemlich unkontrolliert ihr Werk verrichtet haben. Von der Pflege dieser ganz zu schweigen. Nicht zuletzt bauen einige Komponenten auch aus Sicherheits -und Effektivitätsgründen auf Systemd auf, um von bestimmten Vorteilen profitieren zu können. Und auch wenn das bei einigen auf wenig Gegenliebe stösst, passiert das dennoch nicht ohne gute Gründe.

[cosmac]

Das Problem ist aber auch dabei, das einige Programme mittlerweile systemd vorausetzen. udisks2 hat mal ohne funktioniert. Und Udev gehört mittlerweile auch zu systemd

Die eigentliche Frage ist doch, ob man das wirklich als Problem bezeichnen kann.

Nicht wirklich bzw. nur als unbedeutendes Problem. Diese Programme laufen dann eben nicht auf meinem Rechner Bis jetzt hat das noch nicht gestört. Schlimmer finde ich udev, weil es ziemlich aufwendig war, das los zu werden. Und bei dbus habe ich aufgegeben.

Ich neige dazu, alles herauszuwerfen, was ich nicht verstehe; wenn mir dann etwas fehlen sollte, kann ich es ja noch einmal angucken. Policykit, logind, consolekit und dbus sind für mich sehr unklare Bereiche.

Aber zurück zum Thema: wie funktioniert bei sinit denn das "respawn", z.B. der getty-Prozesse? Das würde ich ungern selbst machen, direkt im rc-Script geht es ja nicht.

Um wieder ein wenig abzuschweifen: Braucht man überhaupt ein init-System? Natürlich braucht man diesen speziellen Prozess mit der Nummer 1. Der startet bei mir ein rcS- und ein rc-Script und da steht alles drin, was früher in /etc/init.d/ stand -- naja, fast alles (161 vs. 5898 Zeilen). Dass es zwei Scripte sind, ist auch nur Tradition.

[RobertDebiannutzer]

@cosmac:
Ich habe respawn noch nicht umgesetzt. Für die ttys habe ich folgenden Loop in rc.init eingerichtet (bewusst POSIX-kompartibel*):

Code: Alles auswählen

	for i in 1 2 3 4 5 6; do
		if [ $i = 1 ]; then
			openvt -f -c $i -- /sbin/agetty 38400 tty$i &
		else
			openvt -c $i -- /sbin/agetty 38400 tty$i &
		fi
	done

Für tty1 habe ich die "force" Option (-f) gebraucht, wahrscheinlich, weil die Init-Meldungen tty1 für sich beanspruchen.
BTW: Ob man in stretch getty oder agetty nimmt ist egal, denn

Code: Alles auswählen

lrwxrwxrwx 1 root root 6 Mär  7 19:29 /sbin/getty -> agetty

(Jedenfalls, wenn man kein anderes getty - wie fgetty z.B. - installiert, denn dann ist es vielleicht anders.)

Als respawn habe ich mir einen while-loop überlegt gehabt (ich hatte dazu im Internet ein Beispiel gefunden), doch mein dafür entworfenes /bin/respawn-script hat nicht funktioniert.** Da müsste man mal das respawn aus den ubase-tools von suckless probieren: https://git.suckless.org/ubase/tree/
Als workaround könnte man vielleicht auch den obigen openvt-Befehl in .bash_logout schreiben? Das bräuchte man dann aber wahrscheinlich die "force" Option (-f), wie sie für tty1 nötig ist.

*Die Möglichkeit, die Zahlen-Range für den for-loop wie bei bash zu schreiben, also {1..6}, würde den POSIX-Richtlinien auch keinen Abbruch tun...
**agetty erschien zwar, aber wenn ich den Benutzernamen eingegeben habe und auf Enter gedrückt habe, erschien nicht "Password: ", sondern nur eine newline und nichts ging mehr - Absturz also.
_____

Man muss in Debian auf einige Programme verzichten, wenn man systemd ganz runter haben möchte (außer libsystemd0, das geht nicht. Aber das hatten wir ja schon im anderen Thread diskutiert, gemeinsam mit einigen Auswirkungen.
Zusammenfassung: Alles was von gvfs oder polkit abhängt, ist nicht mehr. Und ohne systemd-logind muss man an einigen Stellen Hand anlegen, z.B. bei den Permissions von /usr/lib/xorg/Xorg.

Wenn man auch udev entfernen möchte, gerät man wohl ziemlich ins Schwitzen?

[MartinV]

Zusammenfassung: Alles was von gvfs oder polkit abhängt, ist nicht mehr.

policykit kann man auch manuell als root starten. Es ist nicht in PATH, aber ausführbar als

Code: Alles auswählen

/usr/lib/policykit-1/polkitd

dbus kann man starten mit

Code: Alles auswählen

dbus-daemon --system

[RobertDebiannutzer]

Mag ja alles sein, doch man muss policykit-1 erstmal installieren können:

Code: Alles auswählen

Depends: dbus, libpam-systemd, libc6 (>= 2.7), libglib2.0-0 (>= 2.37.3), libpam0g (>= 0.99.7.1), libpolkit-agent-1-0 (= 0.105-18), libpolkit-backend-1-0 (= 0.105-18), libpolkit-gobject-1-0 (= 0.105-18)

Ohne systemd als service-manager (init egal) als Abhängigkeit von libpam-systemd geht da nix.

dbus ist kein Problem.

[MartinV]

Hm. Schade, daß libpam-systemd als harte Abhängigkeit definiert ist, nicht als Empfehlung.

Man könnte vielleicht mit equivs-build ein leeres fake-Paket libpam-systemd erstellen.
Oder das policykit-Paket manipulieren und die Abhängigkeit entfernen.
Oder policykit selbst kompilieren.

[Tintom]

policykit-1 hat seit Wheezy keine neue Upstream-Version mehr gesehen und Wheezy war noch vor der systemd-Ära. Vielleicht sind die Abhängigkeiten gar nicht so "stark" und man kann das mit einem Paketneubau schon lösen?!

//EDIT: MartinV war schneller

[MartinV]

Vielleicht sind die Abhängigkeiten gar nicht so "stark" und man kann das mit einem Paketneubau schon lösen?!

Das müßte gehen. Soweit ich sehe, wird libpam-systemd nur gebraucht, um mit systemd-logind zu kommunizieren.
Bekommt polkit keine Antwort von logind, spuckt es beim Login eine Fehlermeldung aus ("keine session für blablub"), funktioniert aber trotzdem, soweit ich sehe. (Jedenfalls in docker Containern).

[RobertDebiannutzer]

Das ist wohl genau das, was Devuan macht...

Wenn man polkit unter Debian haben möchte, gibt es folgende Möglichkeiten:
1. systemd als init und service-manager
2. anderes init aber systemd als service-manager, dann braucht man aber shim
3. Paket modfizieren
4. polkit deinstallieren

Punkt 3 ist schwierig, da schon relativ viel gefummelt wird am System durch die Kombi systemd/libpam-systemd/polkit.
Z.B. kann man als user /dev/sr0 ohne die Kombi* nicht nutzen, d.h. "vlc cdda:///dev/sr0" schlägt fehl. Auch wenn man in der "cdrom"-Gruppe ist! /dev/sr0 ist dann nur für root zugreifbar.
Mit der Kombi* allerdings sehen die Permission so aus: "brw-rw----+ 1 root cdrom". Ist man nun in der cdrom-Gruppe, läufts. (gvfs ist so oder so nicht nötig. Das braucht man AFAIK nur, wenn man auf Audio-CDs wie auf Datei-CDs mit dem Datei-Manager zugreifen möchte.)

*Wobei nicht klar ist, welches Teil nun für diese Änderung zuständig ist. Mal wieder ein bisschen intransparent...

[MartinV]

Wenn man polkit unter Debian haben möchte, gibt es folgende Möglichkeiten:

5.) `elogind` und `libpam-elogind` von devuan nehmen.

Auch wenn man in der "cdrom"-Gruppe ist! /dev/sr0 ist dann nur für root zugreifbar.

Was zeigt denn "ls -l" für Gruppen?

Code: Alles auswählen

ls -l /dev/sr0 /dev/cdrom /dev/cdrom0

[RobertDebiannutzer]

5.) `elogind` und `libpam-elogind` von devuan nehmen.

Kann man einzelne Pakete von Devuan übernehmen?

"ls -l /dev/sr0 /dev/cdrom /dev/cdrom0" kann ich gerade nicht nachschauen. Bald kommt mein neues Notebook und mein jetziges geht an jemand anderes. Da diese andere Person aber nicht so Lust auf init-Veränderungen hat, habe ich wieder systemd installiert. Zum weiteren Testen muss ich also warten, bis mein neues Notebook da ist und ich wieder ein systemd-freies Debian probieren kann.
Aber laut Gedächtnis sahen die Permissions von /dev/sr0 so aus: "brw------- 1 root root" oder so "brw-rw---- 1 root root". Auf jeden Fall gehörte /dev/sr0 nur root und jemand anderes war auch zu nichts berechtigt.