python-daemon-set-sunrise

sting · Mittwoch 13. März 2019, 15:41

Hallo!

Ich bin neu in diesem Forum und auch frisch in der Thematik Python.

Die letzten 2 Wochen habe ich damit verbracht, mir als erstes Projekt einen Linux Daemon zu schreiben, den ich für weitere Projekte nutzen möchte. Da ich open source liebe, habe den Code auf Github gestellt und würde mich sehr freuen, wenn der ein oder andere einen Nutzen daraus ziehen kann.

Zu dem Programm/Daemon:
Es ist ein Daemon der selber keine Aufgabe erfüllt außer ein Daemon zu sein und sich um Configfiles, leveldb, logging und dergleichen zu kümmern. Mein Ziel war es, eine Daemon Hülle zu kreieren, in der ich jedes beliebige Python Skript in wenigen Minuten als Daemon bereitstellen kann.

Das install Skript installiert alle Abhängigkeiten, erstellt auf Wunsch auch einen non-priviledged user oder betreibt den Daemon als root, setzt alle Berechtigungen optimal, erstellt init.d skripts für start/stop/restart/gracefullshutdown/... und vieles mehr.

Ich habe eine ausführliche Anleitung und Dokumentation geschrieben, ich hoffe sie ist schlüssig, wenn nicht, ist Feedback sehr willkommen!

Hier gehts zum Projekt: https://github.com/bithon/python-daemon-set-sunrise

Danke und viel Spaß

DasIch · Mittwoch 13. März 2019, 22:45

Nichts für ungut aber dir ist schon klar dass es eine sehr schlechte Idee ist einen Daemon zu schreiben? Process supervisor und jedes Init System dass nicht vollkommen kaputt ist löst all diese Probleme. systemd ist schon 9 Jahre alt und bei jeder nennenswerten Linux Distribution dabei und ist bei weitem nicht die neuste Option in diesem Gebiet.

So zum lernen ist dies sicherlich interessant aber produktiv einsetzen... naja.

sting · Donnerstag 14. März 2019, 08:54

Hallo Ich!
Ehrlich gesagt, ist mir das nicht klar! Was macht es denn schlecht und was wäre deiner Ansicht nach der bessere/beste Weg?

sparrow · Donnerstag 14. März 2019, 09:01

DasIch möchte damit sagen: systemd und andere moderne init-Systeme tun genau das, was dein Programm auch tut.
Nur benutzt, geprüft und mit auf (fast) allen Systemen verfügbar.

noisefloor · Freitag 15. März 2019, 13:24

Hallo,

und außerdem gibt's auch schon lange supervisord (ist AFAIK auch in Python geschrieben), der ebenfalls das gleiche macht.

Ich sag's auch mal ganz platt: wenn du 2019 das Erstellen von init.d Skripten als Feature hervor hebst, dann hast du echt ein paar Jahre Systementwicklung von Linux verpasst. Das erwähnte systemd ist das, was quasi alle einsetzen und dafür schreibt man systemd Units. Auch wenn systemd aus Gründen der Kompatibilität noch init-Skripte auswertet (bzw. diese "on the fly" in systemd Units wandelt.

Gruß, noisefloor

sting · Sonntag 17. März 2019, 22:00

Ich hab systemd aus Anwender Sicht durchaus mitbekommen, dachte aber nicht, das es so verpönt ist, selber diese Funktionalitäten im eigenen Code abzubilden. Zwar schade, aber dennoch vielen Dank für das Feedback

noisefloor · Montag 18. März 2019, 07:21

Hallo,

Ich hab systemd aus Anwender Sicht durchaus mitbekommen,

Aber scheinbar nicht so richtig. Der eigentlich Kritikpunkt ist, dass du init.d Skripte als Feature propagierst. Womit du ziemlich explizit zum Ausdruck bringst, dass du bzw. der Code auf der Höhe der Zeit ist.

dachte aber nicht, das es so verpönt ist, selber diese Funktionalitäten im eigenen Code abzubilden.

Ist es auch nicht - aber, sagen wir mal so: es ist nicht nötig

Wie oben schon gesagt wurde, setzen so gut wie alle Linux-Distros auf systemd. Die letzte große Distro war Ubuntu, und mit Xenial Xerus im April 2016 war systemd damit zu 100% im Linux-Mainstream.
Zumal es ja so ist, dass du deinen Daemon ggf. über eine systemd Service Unit starten musst. Und dann kann man auch direkt eine systemd Service Unit zum starten des Progs nehmen.
Mit dem Unterschied, dass hinter systemd viel mehr Entwickler stehen, es viel mehr genutzt wird und damit mit ziemlicher Sicherheit 1000x besser getestet ist als dein neuer Daemon.

Was anderes ist es, wenn du das Projekt zu Lernzwecken geschrieben hättest, wie DasIch am 13.3. schon sagte. Dazu hast du dich aber bis dato nicht geäußert...

Gruß, noisefloor

sting · Montag 18. März 2019, 15:52

Hi nosefloor!

Ich habe es für beides geschrieben, zum Lernen und als Basis für weitere Projekte. Persönlich gefällt mir die Freiheit die ich mit dem Projekt habe, ich kann selber status Meldungen mit extra Infos anfüllen, habe volle Kontrolle über das Logging und kann eben alles direkt beeinflussen. Ich muss zugeben, das ich systemd nur oberflächlich kenne und es gab auch nachteiliges zu lesen. Zumindest anfangs gab es sehr viele kritische Stimmen, aber wie gesagt, ich kenns nur oberflächlich, es ist mittlerweile schon alt und wie ihr sagt extrem verbreitet... wird schon was dran sein

ich werde es mir definitiv bald genauer ansehen und dann neu abwägen, was für mich der geeignetere Weg ist.

Danke!

noisefloor · Montag 18. März 2019, 16:52

Hallo,

Ich muss zugeben, das ich systemd nur oberflächlich kenne und es gab auch nachteiliges zu lesen. Zumindest anfangs gab es sehr viele kritische Stimmen,

Richtig - aber das ist ja Standard, wenn was grundlegend neues bei Linux kommt

Wie gesagt, systemd ist DER Standard, auf dem so gut wie alle Linux-Distro setzen. Das ist fest verankert in der Linux-Welt und ich denke, dass sich auf absehbare Zeit daran nicht ändern wird.

Was man für sich selber programmiert ist das eine. Zum Lernen ist das auch genau richtig, dass man das programmiert, was einem Spaß macht - auch dann, wenn man z.B. den 500. Taschenrechner schreiben würde. Weil: dann, also wenn man Spaß hat und einem das Projekt sinnvoll erscheint, lernt man auch was.

Wenn man damit aber an "die breite" Maße" will, dass sollte man sich Gedanken machen und zumindest die "Marktbegleiter" kennen - weil so Fragen wie hier an dich kommen dann ganz von alleine...

Gruß, noisefloor

nezzcarth · Montag 18. März 2019, 22:00

sting hat geschrieben: Montag 18. März 2019, 15:52 Ich habe es für beides geschrieben, zum Lernen und als Basis für weitere Projekte.

Beim Überfliegen des Codes wirkte es so, als ob du den Teil, der die eigentliche Daemon-Funktionalität implementiert aus python-daemon übernommen hast. Wenn das ein Projekt zu Lernzwecken ist, hätte ich erwartet, dass doch gerade die Implementierung eines "klassischen" Daemons mittels Double-Forking usw. zu den Sachen gehört, die man selbst programmieren möchte

(dann weiß man auch, was einem erspart bleibt

) Systemd hat auch Unterstützung für diesen traditionellen Daemon-Typ, den man in Units definieren kann (und in den man pages sogar einer recht gute Erklärung, was man alles tun muss: https://www.freedesktop.org/software/sy ... aemon.html). Allerdings kann man es wie gesagt heute auch einfacher haben.