Projekt "setimgr" fortführen

[RTC]

Kennt einer von euch den setimgr ( http://www.arkady.demon.co.uk/seti/ )? Also das Programm bietet ein Interface zum Abarbeiten mehrerer Crunches sequentiell oder parallel zueinander. Leider wird es nicht mehr fortgeführt (letzte Änderung im März 2002), was ich schade finde, da es doch sehr praktisch ist, aber auch noch einige Bugs enthält.

Ich will das nun Programm weiter programmieren, arbeite mich dazu gerade in den Source ein und habe ihn auch schon etwas umgeschrieben (siehe http://www.linux-related.de ). Problem: das Programm arbeitet mit Signalen. Werden SIGTERM, SIGALRM oder SIGHUP geschickt, dann führt das Programm je nach Konfiguration eine andere Aktion aus.

Ich finde dieses Signal-Konzept unschön, vor allem auch, da die Ausgabe nur auf das tty gelenkt wird, wo der "setimgr"-Hauptprozess läuft. Da ich mit einem Startskript arbeite und alle Ausgabe auf /dev/null umleite, wird mir beim Senden eines Signals natürlich nichts angezeigt.

1. Meine Frage nun: wäre es nicht praktischer, das Programm so umzugestalten, dass es je nach übergebenem Kommandozeilenargument eine andere Aktion ausführt
oder ist das Signalkonzept doch noch die bessere Lösung? Sollte ich die Signale rauslassen, so müsste ich den ganzen Source umstapeln und davor graut es mir ein wenig...

2. Das Programm speichert beim Start die PID des Prozesses im File "setimgr.pid". Problem: wenn mehrere Instanzen des Programms gestartet werden, so wird die alte PID überschrieben. Ruft man nun das erste Mal "kill $(cat setimgr.pid)" auf, so wird die letzte Instanz gekillt und setimgr.pid gelöscht. Will man dasselbe jetzt für die anderen Instanzen tun, so funktioniert das natürlich nicht, weil die Datei gelöscht wurde.
Wäre es praktischer:
a.) einen Stapel anzulegen und dort die PIDs zu speichern, dabei immer die aktuelle PID in setimgr.pid zu schreiben oder
b.) das Starten weiterer Instanzen von setimgr zu unterbinden, indem man überprüft, ob die setimgr.pid existiert? Dies könnte natürlich zu Komplikationen führen, wenn setimgr.pid "illegal" existiert bzw. vom letzten Prozess nicht rechtmäßig gelöscht wurde (anormale Beendigung)...

Wäre gut, wenn jemand kleinere Tipps geben könnte. Ich bin ja schon motiviert, das Programm weiter zu führen, aber für den Anfang wird man etwas überladen, da ist schon das Code-Lesen schwer.

Bye, RTC

[rüdiger]

1. ich würde nicht das Signal Konzept umschreiben, da würde ich lieber verschiedene Scripts schreiben, die die Signale an den Prozess schicken, die PID wird ja in eine Datei geschrieben, also sollte das kein Problem sein.

2. wenn es Sinn macht, dass 2 Prozesse davon existieren, dann ist natürlich die Möglichkeit a besser. Ansonsten würde ich einfach Methode b nehmen. Das ist bei vielen Programmen sehr populär! Damit du keine Probleme mit nicht richtig gelöschten Dateien hast, kannst du ja entweder prüfen ob die Datei vor dem letzten System start erstellt wurde (so schließt du aus, dass nach einem Systemabsturz dei Datei noch vorhanden ist) oder du löscht die Datei in dem Startscript wenn sie existiert (rm -f <blablub> )

[RTC]

Hi kingruedi und danke für's Antworten!

zu 1.) Das Problem ist, dass ich setimgr über ein Runlevel-Skript starte und auch wieder beende. Alle Ausgabe leite ich dabei mittels "setimgr > /dev/null" um. Klar, dass ich so nie eine Ausgabe erhalte, da die Signale ja nur an den Hauptprozess geschickt werden. Deswegen finde ich das Signalkonzept unpraktikabel und stelle mir eher eine Lösung vor, wo verschiedene Teile des Programms ohne Signale aufgerufen werden und somit die Ausgabe immer im aktuellen Terminal stattfindet. Was denkst du darüber? Mit Scripts ließe sich das so sicher nicht gut machen...

zu 2.) Also da man ja auch in der Config einstellen kann, wieviele WUs parallel abgearbeitet werden sollen, ist es schon besser, einen zweiten Prozess zu unterbinden. Ja, das ist populär, nur eine Frage hätte ich dazu noch: wenn der Prozess anormal beendet wurde, dann existiert die Datei trotzdem noch, wenn man sich nun darauf verlässt, dass ein Prozess vorhanden ist, wenn die Datei existiert, dann führt das zwangsläufig zum Chaos. Was ist praktikabel, um festzustellen, ob die PID darin wirklich noch einem laufenden Prozess zugeordnet ist? Kann man da mit Datei-Locking oder so etwas machen bzw. kann man die Datei auslesen und dann feststellen, ob der Prozess mit der PID darin noch existiert? Welche Funktion kann man dafür verwenden, kenne mich leider noch nicht ganz stark mit der Systemprogrammierung aus. Ich bräuchte nur den Namen einer entsprechenden Funktion, den Rest beschaffe ich mir schon.
Kann es dabei zu Konflikten mit Zombie-Prozessen kommen?

Bis später...
RTC

[rüdiger]

zu 1)
hmm, dass ist natürlich ein Problem. Du könntest aber setimgt auch in eine log Datei schreiben lassen und das Script gibt dann diese eben aus

setimgr 2>&1 > /var/log/setimgr

und dann sieht ein Script eben so aus (ungefähr, weiss nicht ob alles klapt ;))

mv /var/log/setimgr /var/log/setimgr.old # backup anlegen
kill -1 `cat pid_file` 2>&1 > /dev/null  # signal senden (hier SIGHUP)
#testen ob kill erfolg hatte (siehe $?)
cat /var/log/setimgr #Augabe von setimgr anzeigen
#Ausgabe an die alte Log anfügen:
cat /var/log/setimgr.old /var/log/setimgr > /tmp/setimgr.tmp
mv /tmp/setimgr.tmp /var/log/setimgr

[rüdiger]

zu 2. ich würde einfach im Startskript die PID Datei löschen, wenn diese vorhanden ist. Wenn diese im normalen Betrieb vorhanden ist, würde ich den User entscheiden lassen, ob er die Datei löschen will oder nicht. Filelocking kannst du wohl auch benutzen, da das wenn der Prozess stirbt AFAIK automatisch freigegeben wird.

[RTC]

Hi kingruedi...

Danke für das Script-Beispiel, aber ich wollte das eben eher programmintern regeln, sodass ich eine Option übergebe und setimgr dann die entsprechende Aktion ausführt, ohne dem Hauptprozess ein Signal zu senden. Im Prinzip wie folgt:
"setimgr" ohne Option: wenn noch keine Instanz von setimgr läuft, dann starte ihn mit eingestellten Optionen aus der setimgr.conf (z.B. ob gedownloadet werden soll nach dem Beenden einer WU, wieviel WUs mit einem mal bearbeitet werden sollen etc.)
"-s" gib Status bearbeiteter WUs aus
"-x" xfer (up/download fertiger WUs)
"-u" User-Status ausgeben
"-k" Hauptprozess setimgr beenden (hier doch mit Signal)
...

Für diese Art von Programm (also wo je nach Option eine andere Aktion ausgeführt wird) finde ich eine Lösung ohne Signale aber schon besser, oder? Ich meine, ich müsste das komplette Programm umstülpen, aber es ergibt sich sicher eine nette Programmieraufgabe

Ich finde es praktikabler ohne Signale, ist heutzutage doch auch eher nicht die allgemeine userfriendly-Praxis, oder? Vielleicht arbeite ich ja auch zu wenig mit Skripts

zu 2.) User entscheiden lassen mag ich nicht so, ich denke eine Automatik ist da schon besser. Hm, irgendwo in meinen Büchern muss da auch was über Filelocking stehen, mal schauen
Noch ne letzte Frage: weißt du nun, wie ich (elegant) mit einer C-Funktion abfragen kann, ob einer PID gerade ein laufender Prozess zugeordnet ist? Bruache bloß den Namen der Funktion, wie oben schon erwähnt, den Rest mach ich selber.

Wünsch mir Glück beim erfolgreichen Umprogrammieren, das Posting hier war mit Sicherheit nicht das Letzte

[rüdiger]

XMMS nutzt so ein System. Naja, im Endeffekt wirst du doch auch über Signale arbeiten, nur dass du die Scripts sozusagen in dein Programm integrierst (oder denkst du dafür lohnt sich ein höheres IPC konzept?)

hmm, dafür kenn ich leider keine standardisierte Lösung

[RTC]

zu 1) Was, xmms nutzt so ein System über Signale? Hm, ich werde sicher wenig über Signale machen, muss mir nur noch überlegen, wie ich das am besten anstelle. Bin grad dabei, mir einen Plan vorzulegen; wenn es Probleme dabei gibt, melde ich mich einfach nochmal...

zu 2) Schade eigentlich. Ich werde mich mal ein wenig umhören, da muss es doch eine Lösung geben?!

Bis denn dann,
RTC

[rüdiger]

1. oh, da hab ich mich leider vertan. XMMS benutzt UNIX-Sockets zum IPC

(wie es genau funktioniert findest du in libxmms/xmmsctrl.c in den XMMS Source)

[RTC]

@kingruedi: eine gute Möglichkeit zu schauen, ob der Prozess mit einer ausgelesenen PID läuft, ist zu schauen, ob das Verzeichnis /proc/PID existiert. Die darin enthaltenen Dateien (z.B. status) können Aufschluss darüber geben, ob es sich bei dem Prozess auch um "setimgr" (oder je nachdem, wie der Binary-Name lautet) handelt.
Oder hast du nen anderen Vorschlag? Eine plattformunabhängige Variante wird es hierfür ja sicher nicht geben (verständlicherweise)