Danke für die Erklärung. Da habe ich die Bedeutung des taskserver.sh Prozesses für napp-it wohl etwas überschätzt und das liegt sicherlich daran, daß ich perl nicht wirklich kenne.
Wenn ich mir das bash-Script "taskserver.sh" allerdings anschaue, wird neben den erwähnten *.sh Shellscripts, die, sofern sie existieren, im Hintergrund durch die Shell abgearbeitet werden, auch *.request Dateien abgefragt und an taskexec.pl weitergereicht. Ich hatte angenommen, daß darüber etwas (also ein request) vom GUI bzw. den automatischen Jobs kommt und entsprechend verarbeitet wird. Aber da lag ich wohl falsch ...
Trotzdem kurz meine Gedanken zum taskserver.sh: Unter linux würde ich das im Script verwendete polling - regelmäßiges überprüfen der Verzeichnisse auf Dateien mit nachfolgendem sleep 1 - ersetzen durch inotifywait. Damit kann man Dateien oder Verzeichnisse (auch ganze Verzeichnisbäume rekursiv) auf Änderungen überwachen. Zwar gibt es inotifywait unter OmniOS bzw. Solaris nicht direkt, aber die Solaris File Event Notification macht offenbar das gleiche. Beschrieben wird das hier und ich habe das dortige C-Program auch schon unter OmniOS kompiliert und kurz getestet. Es war nur eine Zeile im Source Code zu ändern, nämlich
bei den #include Zeilen im Source Code hinzuzufügen. Danach "make" und eine ausführbare Datei entsteht.
Nach dem Starten erkennt diese problemlos, sobald im überwachten Verzeichnis eine Änderung passiert - also beispielsweise eine Datei angelegt wird - und terminiert. In einem Shell Script könnte genau dann eben die neue angelegte Datei wie bisher behandelt werden und die Überwachung des Verzeichnisses wieder gestartet werden. Klarerweise müßte man sich allfällige corner-cases noch überlegen und auch abwägen, ob eine Änderung Sinn macht ode nicht - effizienter sollte es jedenfalls werden, weil die loop: "prüfe Verzeichnis / sleep 1" nicht andauernd durchlaufen würde, sondern eine Prüfung auf auszuführende Dateien nur dann erfolgte, sobald es tatsächlich etwas zum Abarbeiten gibt.
Schließlich denke ich, daß auch eine weitere Änderung in taskserver.sh möglich sein sollte. Sofern ich das bash-Script richtig verstanden habe, sollte der bisherige Codeteil
eigentlich problemlos durch
ersetzt werden können.
Ich bin davon ausgegangen, daß das "sleep 1" mit dem Kommentar "next sleep required" vor den beiden Befehlen "cat && rm" nur sicherstellen soll, daß die Datei "$FILE" nicht gelöscht worden ist, bevor die Abarbeitung durch die shell gestartet wurde, weil ja nicht sichergestellt ist, daß der Befehl "sh $FILE &" tatsächlich ausgeführt wird, bevor die Datei nachfolgend gelöscht wird. Abgesehen davon, daß dies auch durch "sleep 1" nicht garantiert wird, gibt es dafür nach meiner Ansicht einen bessere Möglichkeit: Input redirection. Eine Datei, die von einem Prozeß geöffnet ist (garantiert durch die input redirection) wird durch rm zwar aus dem Verzeichnis entfernt und ist damit für andere Prozesse nicht mehr erreichbar, der Inhalt der Datei steht aber allen Prozessen, welche die Datei noch offen haben - und damit insbesondere der shell, welche das Script ja von standard input liest, bis zu deren Beendigung zur Verfügung. Damit kann das Löschen sofort nach dem Befehl sh < "$FILE" erfolgen, weil dann die Input redirection bereits passiert ist und die Datei geöffnet ist.
Das sind einmal so meine Gedanken - @gea bitte um Feedback, ob das nachvollziehbar ist und sinnvoll wäre oder nicht. Atom2
Wenn ich mir das bash-Script "taskserver.sh" allerdings anschaue, wird neben den erwähnten *.sh Shellscripts, die, sofern sie existieren, im Hintergrund durch die Shell abgearbeitet werden, auch *.request Dateien abgefragt und an taskexec.pl weitergereicht. Ich hatte angenommen, daß darüber etwas (also ein request) vom GUI bzw. den automatischen Jobs kommt und entsprechend verarbeitet wird. Aber da lag ich wohl falsch ...
Trotzdem kurz meine Gedanken zum taskserver.sh: Unter linux würde ich das im Script verwendete polling - regelmäßiges überprüfen der Verzeichnisse auf Dateien mit nachfolgendem sleep 1 - ersetzen durch inotifywait. Damit kann man Dateien oder Verzeichnisse (auch ganze Verzeichnisbäume rekursiv) auf Änderungen überwachen. Zwar gibt es inotifywait unter OmniOS bzw. Solaris nicht direkt, aber die Solaris File Event Notification macht offenbar das gleiche. Beschrieben wird das hier und ich habe das dortige C-Program auch schon unter OmniOS kompiliert und kurz getestet. Es war nur eine Zeile im Source Code zu ändern, nämlich
C:
#include <ctype.h>Nach dem Starten erkennt diese problemlos, sobald im überwachten Verzeichnis eine Änderung passiert - also beispielsweise eine Datei angelegt wird - und terminiert. In einem Shell Script könnte genau dann eben die neue angelegte Datei wie bisher behandelt werden und die Überwachung des Verzeichnisses wieder gestartet werden. Klarerweise müßte man sich allfällige corner-cases noch überlegen und auch abwägen, ob eine Änderung Sinn macht ode nicht - effizienter sollte es jedenfalls werden, weil die loop: "prüfe Verzeichnis / sleep 1" nicht andauernd durchlaufen würde, sondern eine Prüfung auf auszuführende Dateien nur dann erfolgte, sobald es tatsächlich etwas zum Abarbeiten gibt.
Schließlich denke ich, daß auch eine weitere Änderung in taskserver.sh möglich sein sollte. Sofern ich das bash-Script richtig verstanden habe, sollte der bisherige Codeteil
Bash:
# check/run /var/web-gui/_log/tmp/*.sh (initiated prior reboot)
DIR="/var/web-gui/_log/tmp/*.sh"
for FILE in $DIR
do
if [ -f $FILE ]
then
sh $FILE &
echo "sh $FILE &"
# next sleep required
sleep 1
cat $FILE && rm $FILE
echo ''
# echo "$FILE" >> /var/web-gui/_log/remote.log # debug, ps for interactive test at console
ps axw | grep repli-send | grep -v grep
fi
done
Bash:
# check/run /var/web-gui/_log/tmp/*.sh (initiated prior reboot)
DIR="/var/web-gui/_log/tmp/*.sh"
for FILE in $DIR
do
if [ -f $FILE ]
then
sh < "$FILE" &
echo "sh $FILE &"
cat $FILE && rm $FILE
echo ''
# echo "$FILE" >> /var/web-gui/_log/remote.log # debug, ps for interactive test at console
ps axw | grep repli-send | grep -v grep
fi
doneIch bin davon ausgegangen, daß das "sleep 1" mit dem Kommentar "next sleep required" vor den beiden Befehlen "cat && rm" nur sicherstellen soll, daß die Datei "$FILE" nicht gelöscht worden ist, bevor die Abarbeitung durch die shell gestartet wurde, weil ja nicht sichergestellt ist, daß der Befehl "sh $FILE &" tatsächlich ausgeführt wird, bevor die Datei nachfolgend gelöscht wird. Abgesehen davon, daß dies auch durch "sleep 1" nicht garantiert wird, gibt es dafür nach meiner Ansicht einen bessere Möglichkeit: Input redirection. Eine Datei, die von einem Prozeß geöffnet ist (garantiert durch die input redirection) wird durch rm zwar aus dem Verzeichnis entfernt und ist damit für andere Prozesse nicht mehr erreichbar, der Inhalt der Datei steht aber allen Prozessen, welche die Datei noch offen haben - und damit insbesondere der shell, welche das Script ja von standard input liest, bis zu deren Beendigung zur Verfügung. Damit kann das Löschen sofort nach dem Befehl sh < "$FILE" erfolgen, weil dann die Input redirection bereits passiert ist und die Datei geöffnet ist.
Das sind einmal so meine Gedanken - @gea bitte um Feedback, ob das nachvollziehbar ist und sinnvoll wäre oder nicht. Atom2
,
