systemd-Nachbau

19/05/2012 - 13:36 von Markus Wichmann | Report spam
Hi all,

ich bastle gerade an einem Nachbau des systemd (ich find die Idee toll,
aber die Umsetzung... naja, bei mir funktioniert sie schon mal nicht).

Falls einer nicht weiß, was das ist: Es ist im Prinzip ein inetd auf
Drogen: Man konfiguriert für jeden beliebigen Dienst einen Socket
(derzeit geplant sind die Adressfamilien AF_INET, AF_INET6 und AF_UNIX,
sowie die Socket-Typen SOCK_STREAM, SOCK_SEQPACKET und SOCK_DGRAM) und
der systemd baut dann diesen Socket auf und wartet auf Verbindung, um
den Dienst erst dann zu starten. Wenn man das als initd einsetzt, werden
bei Systemstart also im Prinzip keine Dienste mehr gestartet, sondern
erst spàter, wenn sie gebraucht werden.

Ja, dies erfordert, dass man Daemons patcht, aber das wird schon. Das
ist dann der nàchste Schritt, erstmal muss der systemd gehen. :-)

So, ich hatte an ein Abhàngigkeitensystem gedacht. Dabei darf man aber
nur diejenigen Abhàngigkeiten aufschreiben, die nicht durch gegenseitige
Aufrufe von Sockets abgedeckt sind (wenn z.B. der ftpd ins syslog
schreibt, muss man diese Abhàngigkeit nicht aufschreiben, denn sobald
der ftpd wirklich schreibt, wird der syslog durch den Socket gestartet.
Allerdings erfordert z.B. ein an localhost gebundener Service eine
Abhàngigkeit zu dem Job, der "ip link set lo up" ausführt. Und diese
Abhàngigkeit muss sogar laufen, bevor überhaupt der Socket fertig
gemacht wird. Wobei das eh besser ist, wenn alle Abhàngigkeiten erfüllt
sind, wenn die Sockets fertig gemacht werden).

Anmerkungen bisher?

So, dann jetzt die praktischen Fragen: Woran erkenne ich bei einem
Stream-Socket, dass jemand eine Verbindung aufbauen will? Ich habe mal
irgendwo gelesen, dass das durch Schreibbarkeit signalisiert wird.
(select() gibt den Socket in den Write-FDs zurück, poll() und epoll
signalisieren POLLOUT/EPOLLOUT) Das kommt mir auf den ersten Blick etwas
nonintuitiv vor. Sicher, dass nicht auch Lesbarkeit geht? (Das wàre dann
nàmlich bei allen Dateitypen, die mir gerade einfallen, gleich.)

Wie bastel ich das System so, dass es am Ende für die meisten Computer
benutzbar wird? Beispiel: Auf einem Laptop ist ein hochgefahrenes
Netzwerk ein Bonus, aber wichtig ist, dass ein getty hochgefahren wird,
damit der Nutzer sich einloggen kann. Auf einem Server hingegen ist das
getty nebensàchlich, viel wichtiger ist ein hochgefahrenes Netzwerk (und
dass die Sockets bereitstehen).

Gedanken dazu?

Ciao,
Markus
 

Lesen sie die antworten

#1 Rainer Weikusat
20/05/2012 - 22:42 | Warnen spam
Markus Wichmann writes:
ich bastle gerade an einem Nachbau des systemd (ich find die Idee toll,
aber die Umsetzung... naja, bei mir funktioniert sie schon mal nicht).

Falls einer nicht weiß, was das ist: Es ist im Prinzip ein inetd auf
Drogen:



Es ist 'im Prinzip' ein wahlloses Sammelsurium von features aus
wenigstens fuenf unterschiedlichen Programmen (init, cron, atd,
sylogd, irgendwas das Prozessmanagement macht) die jemand, der sich
bislang oeffentlich nicht durch besondere Erkenntnistiefe profiliert
hat[*],


[*] Again, this turned out to be due to a change to D-Bus.
Lennart Poettering had been working on some changes to avoid
libdbus’s awkward SIGPIPE handling and replace it with the use
of the MSG_NOSIGNAL flag. Unfortunately he’d missed a case in
the authentication code.

http://netsplit.com/2010/12/30/the-...ng-tested/

fuer Ganz Besonders Wichtig[tm] hielt und unbedingt mal so
reimplementieren musste, wie er das gemacht haette, wenn er es gemacht
haette. Solche System gibt es wie Sand am Meer (aehnlich wie
'String-Bibliotheken' klassisches 'rite de passage'-Programmieren),
lediglich ist es den meisten 'Entwicklern' von sowas nicht vergoennt,
einen finanzkraeftigen Sponsor in der Hinterhand und eine eigene
Meerschwein-Community, die man ungefragt damit traktieren kann, zur
Verfuegung zu haben.


Man konfiguriert für jeden beliebigen Dienst einen Socket
(derzeit geplant sind die Adressfamilien AF_INET, AF_INET6 und AF_UNIX,
sowie die Socket-Typen SOCK_STREAM, SOCK_SEQPACKET und SOCK_DGRAM) und
der systemd baut dann diesen Socket auf und wartet auf Verbindung, um
den Dienst erst dann zu starten. Wenn man das als initd einsetzt, werden
bei Systemstart also im Prinzip keine Dienste mehr gestartet, sondern
erst spàter, wenn sie gebraucht werden.



Grundsaetzlich ist das eine dumme Idee, denn waehrend ein System
bootet, tut es nichts ausser booten und zu dem Zeitpunkt, an dem ein
Server benoetigt wird, sollte er zur Verfuegung stehen, anstatt erst
gestartet werden zu muessen. In der Theorie jedenfalls. In der Praxis
sind Computer heutzustage ausreichend leistungsfaehig, das
'Optimierungen' dieses Kalibers im allgemeinen keine Rolle mehr
spielen (auch wenn sie moeglicherweise das Problem kaschieren, dass
manche Programme lokal konfigurierte IP-Addressen und DNS-Namen beim
starten vorwaerts und rueckwaers aufzuloesen versuchen, was bei
'unvollstaendiger' Konfiguration des Systems etwas dauert :->).

[...]

Anmerkungen bisher?

So, dann jetzt die praktischen Fragen: Woran erkenne ich bei einem
Stream-Socket, dass jemand eine Verbindung aufbauen will? Ich habe mal
irgendwo gelesen, dass das durch Schreibbarkeit signalisiert wird.
(select() gibt den Socket in den Write-FDs zurück, poll() und epoll
signalisieren POLLOUT/EPOLLOUT) Das kommt mir auf den ersten Blick etwas
nonintuitiv vor. Sicher, dass nicht auch Lesbarkeit geht? (Das wàre dann
nàmlich bei allen Dateitypen, die mir gerade einfallen, gleich.)



Ich denke, Du verwechselst das: Wenn ein sogenannter 'nonblocking
connect' gestartet wurde, wird der zugehoerige Dateibeschreiber
'schreibbar' sobald ein entsprechendes Ergebnis vorliegt. Am anderen
Ende wird ein Deskriptor im Zustand 'listening' lesbar, wenn eine
Verbindung angenommen werden kann.

Wie bastel ich das System so, dass es am Ende für die meisten Computer
benutzbar wird? Beispiel: Auf einem Laptop ist ein hochgefahrenes
Netzwerk ein Bonus, aber wichtig ist, dass ein getty hochgefahren wird,
damit der Nutzer sich einloggen kann. Auf einem Server hingegen ist das
getty nebensàchlich, viel wichtiger ist ein hochgefahrenes Netzwerk (und
dass die Sockets bereitstehen).

Gedanken dazu?



Ein 'Server' bei dem remote-Consolenzugang nicht moeglich ist (zB via
serielle Konsole von einem anderen Computer) ist ein Zustand, dem man
generell zu entkommen suchen sollte: Auch 'Netzwerke' muessen mal
rekonfiguriert werden und dazu sollte man tunlichst einen anderen
Computer als denjenigen, dessen 'Netzwerk' rekonfiguriert werden soll
benutzen ...

Ähnliche fragen