Perl-Script wird faul, wenn aus der Crontab gestartet

P

pygo

Jungspund
Hallo!

Ich habe diesen Thread mal unter Programmierung gestellt, obwohl mein Fehler erst mit Verwendung der crontab eingetreten ist.

Ich habe ein Script, das nach dem Start aus einer Datenbank etwas ausliest (verschiedene Namen für Server) und dann für jeden ausgelesenen Wert einen eigenen Kindprozess startet, die alle die selbe Aufgabe haben. Dabei gehen sowohl Vater als auch alle Kinder in eine Endlosschleife. Dieses Script arbeitet wunderbar, wenn ich es per shell starte.

Jetzt habe ich es - für den Fall, dass es mal abstürzen sollte oder was auch immer - in die crontab geschrieben, damit es sich alle 10 Minuten neu startet. Bei Neustart prüft es dann immer nach einer laufenden Instanz und erst wenn es keine (funktionierende) findet, läuft es neu an.
Komischerweise startet er nicht für alle vorhandenen Werte in der Datenbank ein Kind. Standarmässig sind es momentan 78 Sachen, die er finden sollte, er macht aber mal 44, mal 48. Wenn ich es wieder normal ohne Crontab starte, findet er wieder gleich alle 78.
Das seltsame ist, ich habe eine Möglichkeit, das laufende Script dazu aufzufordern, noch einmal diese Werteliste upzudaten. Wenn ich das nutze, nachdem er nur bspw 44 gestartet hat findet er die anderen 34 auch ohne Probleme und startet sie nach. Das heisst, weder der Zugriff auf die Datenbank noch der Start von so vielen Subprozessen scheint im Endeffekt ein Problem darzustellen.

Der User von Hand und in der Crontab ist auch der selbe, es ist ein Suse Linux System.

Was gibt es für Unterschiede, wenn ein Programm aus der crontab gestartet wird? Hat jemand eine Idee oder kann mir anderweitig auf die Sprünge helfen, warum mein Programm auf einmal faul wird, wenn es unbeobachtet ist? :think:

Vielen Dank!
Pygo
 
cron hat eine eigene Umgebung und auch eigene Umgebungsvariablen, die zu Beginn der /etc/crontab definiert werden.
Schau auch mal, ob das Script irgendwelche Fehler ausspuckt: /var/log/cron /var/log/messages und prüfe die Mailbox von root, da cron Fehler auch dort hinkritzelt.
 
Das Script spuckt überhaupt keine Fehler aus - ich habe mir die Ausgabe bereits extra in eine Datei umgeleitet und da steht nur 'normales' Zeug drin. Unter Root muss ich mal fragen (leider nicht mein eigener Server).

Aber auf jeden Fall werde ich mir mal diese Umgebungsvariablen genauer zu Gemüte führen, ob das mir in irgendwelcher Weise zum Rätsel lösen dienlich ist.

Vielen Dank.
 
Hallo
Unter welcher crontab läuft denn das script?

Eventuell sind ja auch Max-werte für die Datenbank unterschiedlich gesetzt.
An einen Fehler wegen falscher %ENV hatte ich auch erst gedacht.
Aber wenn es scheibar ausgeführt wird, und nur die Returnvalue unterschiedliche Größen haben aber nicht falsch sind...
Die Pfade sollten dann schon alle stimmen.
:think:
Die Einzigen Umgebungsvariablen die mir da einfallen sind halt sowas wie z.B. bei mySQL
max_allowed_packet
usw.

Gruß Wolfgang
 
Sorry for the delay...

Unter welcher crontab? Hm, entweder fehlen mir da jetzt Grundlagen in Linux oder meine Antwort lautet einfach: Unter der von einem Benutzer ohne admin-Rechte.

Peinlicherweise muss ich jetzt zugeben, dass ich etwas genauer was rausgefunden habe: Er liest immer alle Werte ein, die in der Datenbank stehen. Er gibt auch die Anweisung, die entsprechden Kindprozesse zu erzeugen (aufgrund von Pipemechanismen kann er es nicht selbst). Genau bei dieser Befehlsübergabe kommt es zu dem Verlust. Hierfür wird eine named pipe verwendet.
Ich habe es geschafft, das Symptom zu verhindern, indem ich jedesmal vor dem schreiben in die Pipe diese gelockt habe. Aber richtig verstanden habe ich es nicht, denn es hat ja sonst nichts dort reingeschrieben.

Danke Euch auf jeden Fall für die Hinweise, ich hab auf jeden Fall was über crontabs gelernt ;)
 

Ähnliche Themen

Queue für copy Script

[HowTo] TeamSpeak 2 - RC2 - Server (Deutsch/Englisch)

k3b - cdr brennen, ab 226mb geschw. einbruch

Zurück
Oben