Commando in terminal eeuwig laten uitvoerren*

[Lulukai]

Ik heb een bepaald oud en zeer specifiek programma dat ik laat draaien in een terminal. Het wordt opgestart door 1 commando met nog wat opties erachter en moet dan voor 'eeuwig' blijven draaien.

Probleem: af en toe komen er foutmeldingen op, zoals bv. "malloc.c:4628: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed". Hierna wordt het programma afgesloten, wat uiteraard niet de bedoeling is.

Na mijn zoektocht in de grochten van het internet, heb ik geen oplossing voor deze foutmelding gevonden. Wat ik gewoon doe is het programma opnieuw draaien, alles werkt zoals het moet en van die fouten heb ik eigenlijk geen last.

Wat wil ik dus bereiken? Dat ik een commando opstart, en als het wordt beëindigd, moet het direct opnieuw terug uitgevoerd worden. Voorlopig heb ik een klein handigheidje gevonden, gewoon een altijd keer Arrow Up en dan Enter drukken en dan wordt het automatisch opnieuw opgestart. (maar dit is in praktijk moeilijk uitvoerbaar om dit bv. 100 of 1000 keer te doen)
Hier moeten natuurlijk wel betere en robustere oplossingen voor zijn.


OS: Ubuntu
(ik weet dat het doorgaans beter is om de foutmeldingen gewoon op te lossen, maar daar kruipt veel tijd in; terwijl opnieuw opstarten gewoon alles direct oplost)

[Juup]

Tsja een while loopje in je favoriete shell of perl ofzo en je bent er.

[Lulukai]

Juup schreef op dinsdag 20 juli 2010 @ 12:46:
Tsja een while loopje in je favoriete shell of perl ofzo en je bent er.

Ja, maar het moet alleen uitgevoerd worden als er een foutmelding is gekomen.

[vanaalten]

code:

while true; do
  <programma>
done

?

[triet]

Gebruik 'screen' en voer daarin de code van vanaalten uit...

[CH4OS]

ruyckske schreef op dinsdag 20 juli 2010 @ 12:42:
(ik weet dat het doorgaans beter is om de foutmeldingen gewoon op te lossen, maar daar kruipt veel tijd in; terwijl opnieuw opstarten gewoon alles direct oplost)

Toch zou ik hier ook tijd in investeren, als ik het zo zie, zou ik zeggen dat het een SQL-query is dit niet goed is (evt in combinatie met je RDBMS).

[Lulukai]

vanaalten schreef op dinsdag 20 juli 2010 @ 12:47:

code:

while true; do
  <programma>
done

?

Gaat dit niet altijd het programma opnieuw doen starten? Soms draait het een uurtje goed, dan mag het gewoon blijven draaien.

[Wolfboy]

Ik zou supervisord gebruiken, die kan dit allemaal automatisch voor je laten draaien en eventueel kan je nog de webinterface aanzetten om de status bij te houden. Ideaal voor dit soort dingen.

[lordgandalf]

Zo te zien gaat je programma de fout in met het geheugen en daar is niks tegen te doen buiten dan een nieuw vergelijkbaar pakket kopen.

[beefstick]

ruyckske schreef op dinsdag 20 juli 2010 @ 12:55:
[...]

Gaat dit niet altijd het programma opnieuw doen starten? Soms draait het een uurtje goed, dan mag het gewoon blijven draaien.

Ik zou zeggen, probeer het uit, als je server vast loopt weet je dat ook weer.

[Rainmaker]

Lekker ranzig: in je inittab zetten met "respawn".

Anders:

code:

while /usr/bin/blaat; do
date
done

[JohnR]

ruyckske schreef op dinsdag 20 juli 2010 @ 12:55:
[...]

Gaat dit niet altijd het programma opnieuw doen starten? Soms draait het een uurtje goed, dan mag het gewoon blijven draaien.

Niet helemaal, als het nog gestart is, probeert het een nieuwe instantie op te starten. Deze "tip" is ongeveer het beroerdste dat je kunt doen

[YellowOnline]

Eerst en vooral: ik ben geen linux scripter. Het volgende principe zou wel een oplossing moeten zijn die enkele eerder vermelde problemen vermijdt: maak een loop die controleert of het proces nog geladen is in het geheugen. De controle voer je elke x seconden uit (te weinig is downtime, te veel is overbodige overhead). Zodra het proces niet meer bestaat laat je het opnieuw opstarten.

Om toch enige voorbeeldcode te geven:

PowerShell:

For ($i=1;$i -EQ 999999;$i++) 
   {
   Try {Get-Process $applicationName}
   Catch {Run-Process $applicationName}
   Start-Sleep 900
   }

Maar dan in Bash.

[ Voor 26% gewijzigd door YellowOnline op 20-07-2010 14:14 ]

[hammerhead]

JohnR schreef op dinsdag 20 juli 2010 @ 13:59:
[...]

Niet helemaal, als het nog gestart is, probeert het een nieuwe instantie op te starten. Deze "tip" is ongeveer het beroerdste dat je kunt doen

Die snap ik niet helemaal. Op de manier waarop het staat zal het commando "<programma>" toch alleen uitgevoerd worden wanneer de vorige instantiatie weg is (of netjes afgesloten, of gecrahsed).

Uit de tekst van de TS maak ik op dat hij nu het volgende doet:

• Console openen
• programma <ENTER>
• 100 keer Up <ENTER>

Daaruit blijkt dat programma niet forked of iets en pas als het klaar is de console weer voor iets beschikbaar is. Vanwege dit zou de tip van de while loop volgens mij juist zeer geschikt zijn.

Let wel, er zit totaal geen controle of het proces idd al draait (in andere console ofzo), daar dien je zelf als gebruiker voor te zorgen met deze methode.

[Kees]

forked het scriptje zelf automatisch naar de achtergrond, of start je hem met een & erachter, of ben je je terminal 'kwijt'?

In het eerste geval, maakt het uit of hij een minuutje down is, of is dat al teveel?

1. Als hij een minuutje down mag zijn: crontab die checked of het nog draait, en als hij niet draait start hem opnieuw
2. Als hij geen minnutje down mag zijn, maak een scriptje dat elke seconde controleert of hij nog draait, en if not, start hem
3. Als je hem nu met & start, en hij forked niet weg, haal die & weg, pak een screen, en doe daar een while true; do program; done

[ Voor 4% gewijzigd door Kees op 20-07-2010 14:27 ]

[Wolfboy]

YellowOnline schreef op dinsdag 20 juli 2010 @ 14:07:
Eerst en vooral: ik ben geen linux scripter. Het volgende principe zou wel een oplossing moeten zijn die enkele eerder vermelde problemen vermijdt: maak een loop die controleert of het proces nog geladen is in het geheugen. De controle voer je elke x seconden uit (te weinig is downtime, te veel is overbodige overhead). Zodra het proces niet meer bestaat laat je het opnieuw opstarten.

Om toch enige voorbeeldcode te geven:

PowerShell:

For ($i=1;$i -EQ 999999;$i++) 
   {
   Try {Get-Process $applicationName}
   Catch {Run-Process $applicationName}
   Start-Sleep 900
   }

Maar dan in Bash.

Don't reinvent the wheel

Gebruik gewoon http://supervisord.org/, zeer makkelijk om niet stabiele scripts draaiend te houden. En nieuwe services aanmaken, etc..

[Rainmaker]

Bovenstaande scriptjes werken allemaal.

Bijvoorbeeld:

code:

while /usr/bin/blaat

Betekent; wacht totdat proces blaat een exit code geeft.
Is dit 0, ga door.

Het wacht dus netjes tot je proces klaar is...

Maar een deamon die ervoor gebouwd is, klinkt als een beter alternatief.

[JohnR]

hammerhead schreef op dinsdag 20 juli 2010 @ 14:17:
[...]


Die snap ik niet helemaal. Op de manier waarop het staat zal het commando "<programma>" toch alleen uitgevoerd worden wanneer de vorige instantiatie weg is (of netjes afgesloten, of gecrahsed).

Nee, ook als het programma naar de background gaat oid blijft je while loop doorstomen

hammerhead schreef op dinsdag 20 juli 2010 @ 14:17:
Uit de tekst van de TS maak ik op dat hij nu het volgende doet:

• Console openen
• programma <ENTER>
• 100 keer Up <ENTER>

Daaruit blijkt dat programma niet forked of iets en pas als het klaar is de console weer voor iets beschikbaar is. Vanwege dit zou de tip van de while loop volgens mij juist zeer geschikt zijn.

Uit een commando kun jij zien of iets forked Je doet hier aannames die behoorlijk uit de lucht gegrepen zijn. Er is een reden dat het woord assumption met deze drie letters begint.

hammerhead schreef op dinsdag 20 juli 2010 @ 14:17:
Let wel, er zit totaal geen controle of het proces idd al draait (in andere console ofzo), daar dien je zelf als gebruiker voor te zorgen met deze methode.

Daarom is de tip dus zo ondoordacht.

[MartinMeijerink]

JohnR schreef op woensdag 21 juli 2010 @ 11:38:
Uit een commando kun jij zien of iets forked Je doet hier aannames die behoorlijk uit de lucht gegrepen zijn.

Nee hoor, als hij het programma start, en hij doet 100 keer <UP> ENTER, en dat blijkt goed te gaan (programma wordt na iedere crash automatisch opnieuw gestart, tot die 100 bereikt is, oftewel tot de gebufferde <UP> ENTERs op zijn), dan is dat toch al een bewijs dat er niks geforkt wordt!
Die while loop is dus een prima oplossing.

[smesjz]

MartinMeijerink schreef op woensdag 21 juli 2010 @ 17:51:
[...]

Nee hoor, als hij het programma start, en hij doet 100 keer <UP> ENTER, en dat blijkt goed te gaan (programma wordt na iedere crash automatisch opnieuw gestart, tot die 100 bereikt is, oftewel tot de gebufferde <UP> ENTERs op zijn), dan is dat toch al een bewijs dat er niks geforkt wordt!
Die while loop is dus een prima oplossing.

In het kader van begrijpend lezen, deel 1:

Voorlopig heb ik een klein handigheidje gevonden, gewoon een altijd keer Arrow Up en dan Enter drukken en dan wordt het automatisch opnieuw opgestart. (maar dit is in praktijk moeilijk uitvoerbaar om dit bv. 100 of 1000 keer te doen)

Dat Arrow Up / enter heeft natuurlijk alleen betrekking op het feit dat je via Arrow up op de shell het vorige uitgevoerde commando uit je history haalt. Hell, dat werkt zelfs op Windows
Het lijkt me niet dat die app iets van STDIN leest, zeker niet als TS meldt dat ie soms een tijd probleemloos draait. Dat 100..1000 keer doen slaat natuurlijk op de regelmaat van crashen.

@JohnR: die while true loop werkt prima zolang die app niet meteen forkt en exit. Jouw "asssumption" (pun intended) dat die while loop blijft "doorstomen" klopt niet. Je zult altijd maar 1 instantie van de app hebben draaien binnen die console. Dat je niet checkt of het programma al gestart is via een andere console doet niks af aan de werking van zo'n while true loop.

code:

while true; do
  /usr/bin/vim 
done

Als je dit opslaat uitvoert zal je 1 keer vim zie in je process list. Kill of sluit je nu vim dan zie je dat deze weer herstart wordt. Logisch natuurlijk want de volgende iteratie in zo'n while loop wordt pas uitgevoerd wanneer "/usr/bin/vim" klaar is (exit). Dat herstarten stopt pas als je het shell scriptje killt met daarin die while loop.

Vervang je "/usr/bin/vim" door iets als "echo blabla" zie je natuurlijk iets heel anders omdat je scherm dan direct vol staat met blabla. Die echo is vrijwel direct klaar met uitvoer.

Dat je meer controle hebt door iets als supervisord hebt, lijkt me evident. Maar je reactie richting hammerhead is erg kinderachtig.

[MartinMeijerink]

smesjz schreef op donderdag 22 juli 2010 @ 09:36:
Dat Arrow Up / enter heeft natuurlijk alleen betrekking op het feit dat je via Arrow up op de shell het vorige uitgevoerde commando uit je history haalt. Hell, dat werkt zelfs op Windows
Het lijkt me niet dat die app iets van STDIN leest, zeker niet als TS meldt dat ie soms een tijd probleemloos draait.

Helemaal mee eens. Je begrijpt me dus niet (of ik leg het krom uit)...

Dat 100..1000 keer doen slaat natuurlijk op de regelmaat van crashen.

Ik bedoel dus ook, doordat hij 100 keer <UP> Enter indrukt, dat dit dus door de shell wordt gebufferd, en dan mag de applicatie 100 keer crashen, en dan is de toetsenbordbuffer (van de shell dus) leeg, en draait de applicatie helemaal niet meer.

Die app forkt dus niet, en daarom is de while true loop een prima oplossing.

[Liegebeest]

Rainmaker schreef op dinsdag 20 juli 2010 @ 13:32:
Lekker ranzig: in je inittab zetten met "respawn".

Lekker ranzig? Dit is precies waar inittab voor is bedoeld Want met onder init blijft dat kreng draaien, zelfs zonder dat de TS in hoeft te loggen, of ingelogd te blijven.

Overigens, zoals een ander al zei lijkt het er inderdaad op dat de software gewoon buggy is en in de fout gaat met memory allocaties. Tijd voor een vervangend product, als het al zo oud is dat er geen updates meer zijn/komen.

[Rainmaker]

cailin_coilleach schreef op donderdag 22 juli 2010 @ 21:41:
[...]

Lekker ranzig? Dit is precies waar inittab voor is bedoeld Want met onder init blijft dat kreng draaien, zelfs zonder dat de TS in hoeft te loggen, of ingelogd te blijven.

Natuurlijk ook te doen met nohup / screen o.i.d.

De reden dat ik het "ranzig" noem, is omdat het eigenlijk niet meer gebruikt wordt (ook al heb ik hier een Tru64 machine met eenzelfde constructie). Er zijn zoveel van die daemontjes / programmaatjes / scriptjes voor, dat init voor de meeste mensen niet de 1e keus zal zijn.

Overigens, zoals een ander al zei lijkt het er inderdaad op dat de software gewoon buggy is en in de fout gaat met memory allocaties. Tijd voor een vervangend product, als het al zo oud is dat er geen updates meer zijn/komen.

Dat kan natuurlijk niet altijd.

Als de applicatie buissness critical is, zou je eigenlijk gewoon je OS erop aan moeten passen; dit klinkt als een probleem met (g)libc o.i.d.

Zou je eigenlijk eens een virtual kunnen opzetten met RH7.2 o.i.d. en kijken of het daarop blijft draaien. Of gewoon de leverancier vragen welke kernel / libs het programma nodig heeft en wat zij supporten.

Je stelt je dan natuurlijk wel open aan "eeuwenoude" bugs etc, maar dat is meestal niets wat een fatsoenlijke firewall niet kan oplossen. Wordt wel ingewikkelder als je bijvoorbeeld ook nog SAN disken o.i.d. eraan hebt hangen.

[Lulukai]

Bedankt voor alle nuttige reacties tot nu toe!

Wat moet ik nu concreet in de terminal intikken? Ik heb het geprobeerd met die while, maar er gebeurde niets.

[Afvalzak]

ruyckske schreef op zaterdag 24 juli 2010 @ 20:17:
Bedankt voor alle nuttige reacties tot nu toe!

Wat moet ik nu concreet in de terminal intikken? Ik heb het geprobeerd met die while, maar er gebeurde niets.

Je moet een batch scriptje maken (Perl/Python etc.) die de hiervoor aangegeven dingen doet.
Dat scriptje roep je aan vanuit terminal.

[Lulukai]

afvalzak schreef op zaterdag 24 juli 2010 @ 20:34:
[...]


Je moet een batch scriptje maken (Perl/Python etc.) die de hiervoor aangegeven dingen doet.
Dat scriptje roep je aan vanuit terminal.

Klaar en duidelijk. Bedankt aan iedereen voor de oplossingen en het meedenken.

[Lulukai]

Ik heb het gewoon zoals jullie aanraadden met een while-lus in een Shellscript gedaan. Werkte perfect!

[Wolfboy]

cailin_coilleach schreef op donderdag 22 juli 2010 @ 21:41:
[...]

Lekker ranzig? Dit is precies waar inittab voor is bedoeld Want met onder init blijft dat kreng draaien, zelfs zonder dat de TS in hoeft te loggen, of ingelogd te blijven.

Ranzig misschien niet. Maar best wel outdated en veel recentere beheerders (die niet op traditionele unix machines gewerkt hebben) zullen niet volgen hoe/waar het geval gestart wordt

[Liegebeest]

Wolfboy schreef op donderdag 05 augustus 2010 @ 14:44:
[...]
Ranzig misschien niet. Maar best wel outdated en veel recentere beheerders (die niet op traditionele unix machines gewerkt hebben) zullen niet volgen hoe/waar het geval gestart wordt

Zeg knul, noem jij mij nou oud?!



/oldschool