On Thu, 9 Mar 2000, Peter Blancke wrote: Guten Abend! Gestern schrieb ich, dass folgendes Skript per Hand aufgerufen einwandfrei laeuft, nicht aber, wenn man den Aufruf als root in Crontab eintraegt. Das Skript lautet: #!/bin/sh /sbin/init.d/i4l stop /sbin/init.d/i4l_hardware stop /sbin/init.d/i4l_hardware start /sbin/init.d/i4l start /sbin/route add default ippp0 Unter Crontab gestartet, bleibt ein "Zombie" haengen. Jetzt habe ich herausgefunden, dass der Zombie bei den beiden Zeilen /sbin/init.d/i4l_hardware stop /sbin/init.d/i4l_hardware start entsteht. Wenn ich diese auskommentiere, laeuft das Script brav durch, doch ist mir damit nicht gedient. Denn ich muss auch die Hardware stoppen und erneut starten. Vielleicht hilft das jemanden, mir zu helfen. Natuerlich hat das Script Ausfuehrungsrechte fuer root. Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht...
On Thu, Mar 09, 2000 at 11:08:16PM +0100, Peter Blancke wrote:
On Thu, 9 Mar 2000, Peter Blancke wrote:
Guten Abend!
Gestern schrieb ich, dass folgendes Skript per Hand aufgerufen einwandfrei laeuft, nicht aber, wenn man den Aufruf als root in Crontab eintraegt.
Das Skript lautet:
#!/bin/sh /sbin/init.d/i4l stop /sbin/init.d/i4l_hardware stop /sbin/init.d/i4l_hardware start /sbin/init.d/i4l start /sbin/route add default ippp0
Unter Crontab gestartet, bleibt ein "Zombie" haengen.
Was denn fuer ein Zombie? Falls es ein 'modprobe' ist, versuche mal ein 'sleep 1' zwischen i4l_hardware stop und start.
Jetzt habe ich herausgefunden, dass der Zombie bei den beiden Zeilen
/sbin/init.d/i4l_hardware stop /sbin/init.d/i4l_hardware start
-- Klaus Franken, mail@klaus.franken.de ------------------------------------------------------------ D O N ' T P A N I C !!! ------------------------------------------------------------ Uptime: Linux 2.2.13, 70 Days, 17:48 Hours
On Fri, 10 Mar 2000, Klaus Franken wrote:
Was denn fuer ein Zombie? Falls es ein 'modprobe' ist, versuche mal ein 'sleep 1' zwischen i4l_hardware stop und start.
Ich habe jetzt das Script /root/isdnreload wie folgt geschrieben: #!/bin/sh /sbin/init.d/i4l stop sleep 2 /sbin/init.d/i4l_hardware stop sleep 2 /sbin/init.d/i4l_hardware start sleep 2 /sbin/init.d/i4l start Rufe ich es per Hand auf (/root/isdnreload), rennt es einwandfrei durch, rufe ich es per Crontap auf, sehe ich unter "top" 1 zombie laufen. pstree verraet mir dann noch folgendes: init-+-atd |-cron---cron-+-isdnreload | `-sendmail und der muesste doch wohl verschwunden sein, denn das Script kennt ja keine Pausenanweisungen. "ps -ax" sagt dazu: 20260 ? S 0:00 /USR/SBIN/CRON 20261 ? Z 0:00 (isdnreload <zombie>) Uebrigens: Wenn ich nach Feststellen dieses Zombies dann noch einmal isdnreload per Hand startet, ist der untote Freund dann ebenfalls verschwunden, dann auch erst erhalte ich ploetzlich die Ausgaben als Mail zugestellt, vorher nicht. Das alles mit Original-Scripts der SuSE 6.1. Die Erhoehung der Zeiten auf 5 Sekunden (am Ende gar auf 10) aendert gar nichts. Hmmm... Ich mische ja schon seit einigen Jahren in Linux mit, aber irgend wie scheitert hier jegliches Verstaendnis. Mittlerweile loese ich das Problem der ISDN-Verlangsamung (unter 6.1 beobachtet, unter SuSE-Supportdatenbank mit Update auf einen Kernel 2.2.13 angeblich zu beheben, kann ich hier aber nicht durchfuehren) durch Ausfuehrung eines "init 1" und "init 2" per Crontab. Das war eigentlich nicht das, wozu ich greifen wollte. Ich suche eben auch nach der Loesung dieses merkwuerdigen Verhaltens. Danke erst einmal fuer Loesungsversuche an Axel und Klaus. Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht...
On Thu, Mar 09, 2000 at 23:08 +0100, Peter Blancke wrote:
Gestern schrieb ich, dass folgendes Skript per Hand aufgerufen einwandfrei laeuft, nicht aber, wenn man den Aufruf als root in Crontab eintraegt.
Das liegt meist auch an Unterschieden zwischen interaktivem Aufruf aus einer Shell mit User dran und unbeabsichtigtem Lauf aus Boot- oder Hintergrund-Mechanismen: Umgebungsvariablen, Pfade, etc. Aber das ist hier nicht das Problem, sondern nur ein Tip fuer aehnliche Probleme.
Das Skript lautet:
#!/bin/sh /sbin/init.d/i4l stop /sbin/init.d/i4l_hardware stop /sbin/init.d/i4l_hardware start /sbin/init.d/i4l start /sbin/route add default ippp0
Unter Crontab gestartet, bleibt ein "Zombie" haengen.
Jetzt habe ich herausgefunden, dass der Zombie bei den beiden Zeilen
/sbin/init.d/i4l_hardware stop /sbin/init.d/i4l_hardware start
entsteht. Wenn ich diese auskommentiere, laeuft das Script brav durch,
Zombies sind an sich nichts Schlimmes: Da endet nur ein Prozess, ohne dass dessen Elternprozess seinen Exitstatus ausgewertet hat. Das kann ja noch passieren, und Ressourcen sind ausser einer Prozessbeschreibung keine mehr gebunden (wird hier immer wieder gefragt und beantwortet). Den Effekt beobachte ich hier auch immer, wenn cronjobs "laenger dauern" (Monitore oder Dialoge starten, tail -f auf Logfiles lassen, usw). crond(8) will noch die Ausgaben wegfangen und per Mail verschicken. Meist gammelt dann auch im mailq(1) output eine offene Message herum. In diesem Zusammenhang: haengt im i4l_hardware nicht der isdnlog drin? Oder werden da andere Prozesse in den Hintergrund geschoben und laufen weiter? Dummerweise habe ich auch mit nohup(1) keine Erfolge bei aehnlichen Jobs gehabt. Aber ich habe dann einfach nicht weiter gesucht -- es laeuft ja alles und ein Zombie ist kein Problem. Vielleicht hilft Dir at(1) weiter. Falls Du dort den beobachteten Effekt nicht hast, kannst Du damit crond(8) emulieren aehnlich wie man manchmal mit signal(2) umgeht: Starte mit at(1) ein Script, das die eigentliche Funktion ausfuehrt und sich selbst wieder mit at(1) auf Halde legt. Falls at(1) die Loesung ist, tu das hier bitte kund.
Vielleicht hilft das jemanden, mir zu helfen. Natuerlich hat das Script Ausfuehrungsrechte fuer root.
Klar, sonst wuerde ja GAR NICHTS passieren. BTW kriegst Du den gewollten Effekt (Route durch ippp0) sicher auch mit dem "offiziellen" Weg: Wer "i4l start" und "i4l_hardware start" ruft, sollte auch "route start" sagen. Sieh Dir mal spasseshalber unter diesem Aspekt "ls /sbin/init.d/rc2.d/S*" an. Auch das kommt hier regelmaessig vorbei (oder tat es frueher immer wieder). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
participants (3)
-
Gerhard Sittig -
Klaus Franken -
Peter Blancke