☰

Ist es sinnvoll, einen Hintergrundjob innerhalb eines Init-Skripts zu erstellen, wenn der Prozess sich nicht selbst als Daemon ausführen kann?

tag-icon • tag-icon init-script daemon
Ist es sinnvoll, einen Hintergrundjob innerhalb eines Init-Skripts zu erstellen, wenn der Prozess sich nicht selbst als Daemon ausführen kann?

Ich bin ziemlich neu bei *nix und bin auf die Notwendigkeit gestoßen, mehrere Prozesse, die 100 % der Zeit ausgeführt werden sollten, mithilfe von in den Hintergrund zu verschieben &.

Dazu verwende ich in einem init.d-Skript (das ich als Benutzer ausführe) die folgende Zeile user:

su -c 'process arg1 arg2 -w - | process2 arg1 -r - &' user

(wobei -w in STDOUT, STDIN schreibt und -r von STDOUT, STDIN liest)

Mir ist nämlich bewusst, dass dies nicht grundsätzlich akzeptabel ist, da die Prozesse nicht gut vor äußeren Einflüssen geschützt sind.

Ist es akzeptabel, Hintergrundjobs für „Dienste“ zu erstellen?

Sollte ich stattdessen eine FIFO/Named Pipe zur Abwicklung der Interprozesskommunikation verwenden?

Wenn ja, sollte ich beide Prozesse trotzdem als Hintergrundjobs erstellen? Ist das stabil?

Näheres hierzu finden Sie unterdieser Mailinglisten-Thread.

Danke,

Matt

Antwort1

Mir ist nämlich bewusst, dass dies nicht grundsätzlich akzeptabel ist, da die Prozesse nicht gut vor äußeren Einflüssen geschützt sind.

Ist es akzeptabel, Hintergrundjobs für „Dienste“ zu erstellen?

Wenn es keinen anderen Weg gibt (das heißt, der Dienst wird nicht von selbst geforkt), dann wahrscheinlich ja. Debian start-stop-daemonhat einen --backgroundParameter für solche Fälle:

   -b, --background
          Typically used with programs that don't  detach  on  their  own.
          This option will force start-stop-daemon to fork before starting
          the  process,  and  force  it  into  the  background.   WARNING:
          start-stop-daemon  cannot  check  the exit status if the process
          fails to execute for any reason. This is a last resort,  and  is
          only  meant  for  programs  that either make no sense forking on
          their own, or where it's not feasible to add the code  for  them
          to do this themselves.

Antwort2

Da die erste Frage bereits beantwortet wurde, werde ich mich auf die letzten beiden konzentrieren.

Vor einigen Tagen hatte ich mit einem ähnlichen Problem zu kämpfen: Ich musste einige Prozesse über Pipes aus Skripten starten . Um das zu lösen, habe ich mir RHEL6 ( und von ) und Debian ( ) /etc/init.dangesehen . Dabei stellte ich fest, dass beide nicht (sehr gut) mit Pipes umgehen konnten. Selbst wenn es irgendwie möglich war, sie zu starten, gab es große Probleme, sie zu stoppen. Daher habe ich ein kleines Tool geschriebendaemonkillproc/etc/init.d/functionsstart-stop-daemonpipexec. Dieses Programm startet eine Pipe von Programmen, verhält sich aber wie ein einziges Programm. Beispiel: Wenn eine SIGTERMgesendet wird, beendet es alle untergeordneten Programme und anschließend sich selbst. Auch die Handhabung von PID-Dateien wird unterstützt – was Ihnen das Leben bei der Integration mit RHEL6 und pipexecerleichtert .daemonkillproc

Sollte ich stattdessen eine FIFO/Named Pipe verwenden, um die Interprozesskommunikation abzuwickeln? Wenn ja, sollte ich dann trotzdem beide Prozesse als Hintergrundjobs erstellen? Ist das stabil?

Ich habe auch darüber nachgedacht - aber für mich ist das zu kompliziert und ich habe nicht wirklich gute Erfahrungen mit FIFOs bezüglich Stabilität und Zuverlässigkeit gemacht (vielleicht ist das mein Problem - aber deshalb benutze ich sie selten ;-) )

Ich habe die Integration pipexecmit RHEL6 durchgeführt und es gibt keine Probleme, es läuft einfach.

Liebe Grüße - Andreas

verwandte Informationen