Hallo!
Ja, diese Liste gibt es noch. Ich habe folgenes Init-Script: https://github.com/netAction/CUL_FS20/blob/master/CUL_FS20.initscript
Das Problem ist, dass es meinen Server nicht mit dem richtigen User ausführt. Das zweite Problem ist, dass beim Ablehnen vom Start nicht im PID-File geprüft wird, ob es überhaupt eine gültige PID enthält.
Vielleicht könnte mir jemand helfen? Wenn es etwas Fertiges gibt, ich hänge nicht an dem Script.
Liebe Grüße Thomas
Thomas Schmidt schmidt@netaction.de (So 08 Dez 2013 19:58:55 CET):
Hallo!
Ja, diese Liste gibt es noch. Ich habe folgenes Init-Script: https://github.com/netAction/CUL_FS20/blob/master/CUL_FS20.initscript
Das Problem ist, dass es meinen Server nicht mit dem richtigen User ausführt. Das zweite Problem ist, dass beim Ablehnen vom Start nicht im PID-File geprüft wird, ob es überhaupt eine gültige PID enthält.
Was meinst Du mit „Ablehnen vom Start“? Nur von der Existenz eines PID-Files den Start oder Nicht-Start abhängig zu machen, ist eine ziemlich heiße Sache.
Das Mindeste, was Du tun solltest, ist, wenn ein PID-File vorhanden ist, gucken, ob es einen Prozess mit der entsprechenden PID gibt. Wenn nicht, dann kannst Du stillschweigend davon ausgehen, dass es beim letzten Mal übrig geblieben ist.
Wo im Script ist der „richtige Nutzer“ zu sehen? Ich hätte ein „su“ erwartet, auf den „richtigen Nutzer“.
Und der Script sollte beim start) mal sicherheitshalber ein „cd /“ machen, oder in ein anderes Verzeichnis, das auch tatsächlich vorhanden bleibt. Und vielleicht noch ein „export LC_ALL=POSIX“.
Vielleicht könnte mir jemand helfen? Wenn es etwas Fertiges gibt, ich hänge nicht an dem Script.
Ich meine, die meisten Distros haben Beispielscripte am Start, mitunter als /etc/init.d/skeleton oder ähnlich.
Und vorallem, die meisten Distros verwenden inzwischen etwas wie „startproc“ oder „start-stop-daemon“ um Prozesse im Init-Script zu starten und ggf. die PID irgendwo wiederzufinden.
Heiko
Hi Heiko!
Ohje, habe ich Ausdrucksschwierigkeiten.
Ich habe folgenes Init-Script: https://github.com/netAction/CUL_FS20/blob/master/CUL_FS20.initscript
Das Mindeste, was Du tun solltest, ist, wenn ein PID-File vorhanden ist, gucken, ob es einen Prozess mit der entsprechenden PID gibt. Wenn nicht, dann kannst Du stillschweigend davon ausgehen, dass es beim letzten Mal übrig geblieben ist.
Genau so stelle ich mir das auch vor.
Wo im Script ist der „richtige Nutzer“ zu sehen? Ich hätte ein „su“ erwartet, auf den „richtigen Nutzer“.
Genau, ich würde gerne den Benutzer wechseln im Init-Script. Ein „su“ könnte ich auch selbst hinbekommen, aber da ich nicht quer durch die Distros testen kann, würde ich mich sehr über eine Lösung von einem alten Bash-Hasen freuen.
Und der Script sollte beim start) mal sicherheitshalber ein „cd /“ machen, oder in ein anderes Verzeichnis, das auch tatsächlich vorhanden bleibt. Und vielleicht noch ein „export LC_ALL=POSIX“.
Danke, das habe ich schon mal geändert.
Ich meine, die meisten Distros haben Beispielscripte am Start, mitunter als /etc/init.d/skeleton oder ähnlich.
Da ich nicht weiß, was die User für ein Betriebssystem haben, hätte ich gerne eine etwas allgemeingültigere Lösung. Außerdem hat meine /etc/init.d/skeleton auch keinen Benutzerwechsel drin.
Und vorallem, die meisten Distros verwenden inzwischen etwas wie „startproc“ oder „start-stop-daemon“ um Prozesse im Init-Script zu starten und ggf. die PID irgendwo wiederzufinden.
Ich habe erst mit Upstart experimentiert, aber nicht mal Debian Wheezy hat das standardmäßig aktiviert. Daher bin ich mit Abhängigkeiten vorsichtig.
Hoffentlich verstehst du jetzt, was ich meine.
Viele Grüße Thomas
Hallo Thomas,
Thomas Schmidt schmidt@netaction.de (Mo 09 Dez 2013 13:50:23 CET):
Hi Heiko!
Ohje, habe ich Ausdrucksschwierigkeiten.
Ich habe folgenes Init-Script: https://github.com/netAction/CUL_FS20/blob/master/CUL_FS20.initscript
Das Mindeste, was Du tun solltest, ist, wenn ein PID-File vorhanden ist, gucken, ob es einen Prozess mit der entsprechenden PID gibt. Wenn nicht, dann kannst Du stillschweigend davon ausgehen, dass es beim letzten Mal übrig geblieben ist.
Genau so stelle ich mir das auch vor.
Teile davon findest Du im status-Teil Deines Scripts. Verwerte doch diesen Teil.
Wo im Script ist der „richtige Nutzer“ zu sehen? Ich hätte ein „su“ erwartet, auf den „richtigen Nutzer“.
Genau, ich würde gerne den Benutzer wechseln im Init-Script. Ein „su“ könnte ich auch selbst hinbekommen, aber da ich nicht quer durch die Distros testen kann, würde ich mich sehr über eine Lösung von einem alten Bash-Hasen freuen.
Na, Moment, „su“ sollte überall gleich funktionieren.
Nicht Bash, Sh :) Die Distros mögen da in den Init-Scripte die Verwendung der Bash nicht wirklich. Wobei ich jetzt die einzelnen Policies nicht kenne…
Und der Script sollte beim start) mal sicherheitshalber ein „cd /“ machen, oder in ein anderes Verzeichnis, das auch tatsächlich vorhanden bleibt. Und vielleicht noch ein „export LC_ALL=POSIX“.
Danke, das habe ich schon mal geändert.
Besser also
LC_ALL=POSIX export LC_ALL
Weil das in einer Zeile abzuwickeln könnte Bashismus sein.
Ich meine, die meisten Distros haben Beispielscripte am Start, mitunter als /etc/init.d/skeleton oder ähnlich.
Da ich nicht weiß, was die User für ein Betriebssystem haben, hätte ich gerne eine etwas allgemeingültigere Lösung. Außerdem hat meine /etc/init.d/skeleton auch keinen Benutzerwechsel drin.
Und vorallem, die meisten Distros verwenden inzwischen etwas wie „startproc“ oder „start-stop-daemon“ um Prozesse im Init-Script zu starten und ggf. die PID irgendwo wiederzufinden.
…
Hoffentlich verstehst du jetzt, was ich meine.
So leidlich. Aber ich denke, ich werde Dir den Script nun doch nicht schreiben, sondern schlage vor, Du schreibst ihn und stellst das dann hier zur Diskussion.
Einen Ausgangspunkt scheinst Du ja schon zu haben, also baust Du noch das mit dem „su“ ein und den Verzeichniswechsel, ebenso noch das Herstellen eines sicheren Environments.
Und dann gucken wir mal weiter.
Hi Heiko!
Ich habe den kompletten Tag mit Start-Scripten herumgebastelt. Mal hat der Server den Startprozess blockiert anstatt als Daemon weiterzulaufen, mal lies er sich nicht vollständig abschießen. Ich habe so ziemlich alles durchprobiert, was ich im Netz finden konnte, natürlich auch start-stop-daemon und /etc/init.d/skeleton.
Nun habe ich mich entschieden nur ein einfaches Startscript zu veröffentlichen und es einfach in der crontab zu starten. Weiterhin habe ich mir vorgenommen Debian nicht mehr leiden zu können und mich zu freuen, dass meine Server Ubuntu haben. :-)
Vielen Dank dennoch für dein Angebot Thomas
Hallo Thomas,
Thomas Schmidt schmidt@netaction.de (Di 10 Dez 2013 23:25:15 CET):
Ich habe den kompletten Tag mit Start-Scripten herumgebastelt. Mal hat der Server den Startprozess blockiert anstatt als Daemon weiterzulaufen, mal lies er sich nicht vollständig abschießen. Ich habe so ziemlich alles durchprobiert, was ich im Netz finden konnte, natürlich auch start-stop-daemon und /etc/init.d/skeleton.
Kannst Du genau beschreiben, was passieren soll? Und was Du versuchst, zu starten? Und wie man prüfen kann, ob es funktioniert hat.
Was man so alles im Netz finden kann, das muss nicht unbedingt von der Qualität sein, die Du erwartest. Man findet viel im Netz :)
Nun habe ich mich entschieden nur ein einfaches Startscript zu veröffentlichen und es einfach in der crontab zu starten.
??? Bitte was ist daran jetzt besser als an einem Init-Script? Ich denke, Admins werden Dich dafür nicht leiden können, denn die erwarten gemeinhin, dass Dienste über init-Script gestartet werden. (Oder über andere Mechanismen, die spezifisch für das jeweilige init-System sind.) Jedenfalls wird niemand erwarten, in der Crontab die Hinweise auf den Start Deines Dienstes zu finden.
Weiterhin habe ich mir vorgenommen Debian nicht mehr leiden zu können und mich zu freuen, dass meine Server Ubuntu haben. :-)
Bloss gut, dass Ubuntu mit Debian nichts zu tun hat. Ubuntu verwendet allerdings Upstart, bei Debian - glaube ich - geht der Trend mehr in Richtung systemd, bin mir aber nicht sicher. Ich bin hier noch ganz Oldschool, meine Systeme müssen nicht täglich neu starten, so dass mir sysv-init gut passt, da verstehe ich wenigstens, was wann passiert.
On Wed, Dec 11, 2013 at 09:23:16AM +0100, Heiko Schlittermann wrote:
Weiterhin habe ich mir vorgenommen Debian nicht mehr leiden zu können und mich zu freuen, dass meine Server Ubuntu haben. :-)
Bloss gut, dass Ubuntu mit Debian nichts zu tun hat.
:-)
Ubuntu verwendet allerdings Upstart, bei Debian - glaube ich - geht der Trend mehr in Richtung systemd, bin mir aber nicht sicher. Ich bin hier noch ganz Oldschool, meine Systeme müssen nicht täglich neu starten, so dass mir sysv-init gut passt, da verstehe ich wenigstens, was wann passiert.
Das Thema upstart vs. systemd liegt grad zur Entscheidung beim Technical Committee [1], derzeit ist sysv-init noch das Standard-Init-System. Auf der DebConf 13 war das auch ein recht kontrovers diskutiertes Thema.
Auch wenn systemd oder upstart mal das Standard-System werden sollte, wird wohl noch eine lange Zeit sysv-init unterstützt werden, weil das auch viele Debian-Entwickler weiter verwenden werden. Für langlaufende Server bringt ein event-basiertes Init-System ja auch erstmal nicht so riesige Vorteile.
Viele Grüße Jan
[1] https://wiki.debian.org/Debate/initsystem
Hi Heiko!
Am 11. Dezember 2013 09:23 schrieb Heiko Schlittermann hs@schlittermann.de:
Kannst Du genau beschreiben, was passieren soll? Und was Du versuchst, zu starten? Und wie man prüfen kann, ob es funktioniert hat.
Ich habe ein Programm in node.js. Es wird als einfacher Benutzer gestartet mit dem Befehl "/usr/sbin/node /usr/share/CUL_FS20/app.js". Der Benutzername und die Pfade sind in jeder Installation anders.
Dieses Programm soll beim Systemstart gestartet werden. Das Kontrollprogramm des Daemons sollte status, stop, restart und start beherrschen. Bei "stop" kann es einfach gekillt werden. Ein Logfile brauche ich nicht, das habe ich jetzt innerhalb vom Programm gelöst.
Der Prozess heißt "CUL_FS20". Es wird wohl reichen, das Vorhandensein so eines Prozesses zu prüfen um zu wissen, ob der Daemon läuft. pstree sagt: bash───CUL_FS20───4*[{CUL_FS20}]
Viele Grüße Thomas
Am 11.12.13 10:08, schrieb Thomas Schmidt:
Hi Heiko!
Am 11. Dezember 2013 09:23 schrieb Heiko Schlittermann hs@schlittermann.de:
Kannst Du genau beschreiben, was passieren soll? Und was Du versuchst, zu starten? Und wie man prüfen kann, ob es funktioniert hat.
Ich habe ein Programm in node.js. Es wird als einfacher Benutzer gestartet mit dem Befehl "/usr/sbin/node /usr/share/CUL_FS20/app.js". Der Benutzername und die Pfade sind in jeder Installation anders.
Dieses Programm soll beim Systemstart gestartet werden. Das Kontrollprogramm des Daemons sollte status, stop, restart und start beherrschen. Bei "stop" kann es einfach gekillt werden. Ein Logfile brauche ich nicht, das habe ich jetzt innerhalb vom Programm gelöst.
Der Prozess heißt "CUL_FS20". Es wird wohl reichen, das Vorhandensein so eines Prozesses zu prüfen um zu wissen, ob der Daemon läuft. pstree sagt: bash───CUL_FS20───4*[{CUL_FS20}]
Da habe ich mit restartd gute Erfahrungen gemacht: Restartd is a daemon for checking running and not running processes. It reads the /proc directory every n seconds and does a POSIX regexp on the process names. You can execute a script or a program if the process is or is not running.
# Example: # # restartd ".*restartd" "/bin/echo 'It is not running!'
/tmp/restartd.out" "/bin/echo 'It is running!' >/tmp/restartd.out"
Grüße
Konrad
On 09.12.13 Heiko Schlittermann (hs@schlittermann.de) wrote:
Moin,
Besser also
LC_ALL=POSIX export LC_ALLWeil das in einer Zeile abzuwickeln könnte Bashismus sein.
LC_ALL=POSIX export LC_ALL
Sollte auch in sh funktionieren.
H.
Hilmar Preusse hille42@web.de (Di 10 Dez 2013 23:32:35 CET):
On 09.12.13 Heiko Schlittermann (hs@schlittermann.de) wrote:
Moin,
Besser also
LC_ALL=POSIX export LC_ALLWeil das in einer Zeile abzuwickeln könnte Bashismus sein.
LC_ALL=POSIX export LC_ALL
LC_ALL=POSIX; export LC_ALL
Sollte auch in sh funktionieren.
Jetzt :) Ich hätte schreiben sollen „in einem Statement“.
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Hilmar Preusse -
Jan Dittberner -
Stefan Konrad Riedel -
Thomas Schmidt