@WooShell@chaosfurs.social @hikhvar@norden.social Schau, das ist genau die Art 50 Jahre alter Unsinns-Ansichten, die Dich zurück hält, wenn es um moderne Systeme geht. Einen Daemon zu schreiben und zu debuggen war der totale Schmerz im Hintern. fork(), Parent beendet sich, Child läuft weiter ist kein Process Group Leadersetsid(), kein Controlling Terminal mehr, neuer Session Leader, neuer Process Group Leader.Noch ein fork(); dies ist dann kein Session Leader mehr und kann daher kein Controlling Terminal mehr bekommen. Meist noch einmal alle fd closen, stdin, stdout, stderr umleiten oder schließen, SIGHUP etc einrichten, und PID Datei managen. syslog() verwenden statt printf(). Und all den ganzen Zirkus nicht machen, wenn -f/--foreground verwendet wird, damit man den Ranz debuggen kann. === All das brauchst Du bei systemd genau nicht mehr, systemd macht das für Dich. Ein systemd-Daemon ist ein normales Linux-Programm, das nach Fehler nach stderr loggt. fork, setsid, und so weiter entfallen. systemd stellt einheitlich und kontrolliert die Umgebung bereit, managed ein pidfile und kümmert sich um Setup und Abräumen der Umgebung. Debugging/Entwicklung und Deploy sind identisch. Und Log Handling auch (journald im Auto-Mode mit forward nach syslog, wenn Du ein Traditionalist bist) Das ist jetzt seit 2010 so, also mal knappe 15-16 Jahre. Eventuell sollten auch Greybeards mal dazu lernen, und vor allen Dingen verstehen, was das hüpfende Komma bei dieser Aktion ist. Da haben nämlich ein paar sehr schlaue Leute lange drauf rum gedacht.