[crontab]wat gebeurt er als taken dubbel lopen?*

[hobbeldebobbel]

ik heb nu een backup crontab lopen die om het kwartier herhaalt wordt.
so far so good.
maar wat ik me nu afvraag, als er veel veranderd is aan de bestanden dan kan de transfer misschien langer gaan duren dan 15 minuten. Dan zal dus ook een nieuwe cronjob opgestart worden...

of gaat crontab pas met de volgende instantie van een job beginnen als een eerdere afgelopen is?

[BCC]

Je crontab zal gewoon starten. Het makkelijkst kun je hiervoor boven in je scriptje kijken of er een bepaald bestaand bestaat (lock file) zo nee, deze aanmaken en verder gaan. Aan het eind van je scriptje moet je deze natuurlijk weer weggooien, zodat je de volgende keer weer kan starten. Helemaal fool proof is dit natuurlijk niet, maar met een gat van 15 minuten zul je waarschijnlijk geen last krijgen van racing conditions

[ Voor 20% gewijzigd door BCC op 13-06-2006 12:47 ]

[bakkerl]

BCC schreef op dinsdag 13 juni 2006 @ 12:46:
Je crontab zal gewoon starten. Het makkelijkst kun je hiervoor boven in je scriptje kijken of er een bepaald bestaand bestaat (lock file) zo nee, deze aanmaken en verder gaan. Aan het eind van je scriptje moet je deze natuurlijk weer weggooien, zodat je de volgende keer weer kan starten. Helemaal fool proof is dit natuurlijk niet, maar met een gat van 15 minuten zul je waarschijnlijk geen last krijgen van racing conditions

En bij je startup scripts ook het lock bestandje verwijderen. Anders zou je bij een spontane reset/stroom uitval/<verzin nog een reden> je backup niet meer lopen omdat het bestandje nog eeuwig bestaat.

[BCC]

True

[hobbeldebobbel]

all right....
alleen weet ik nog niet hoe ik een bestandje moet maken,of wel checken in zon script...
maar daar ga ik maar eens even naar zoeken

thanx

[Blorgg]

Voor het geval dat je script vastloopt of als er iets anders onverwacht gebeurd, zou ik met timestamps werken. Dus dat je de starttijd van het script in de lockfile opneemt. Mocht deze dan een bepaalde tijd oud zijn, dan kun je een mailtje sturen dat er iets mis is, of de taak alsnog uit gaan voeren om maar iets te noemen.

[BCC]

touch mylock.lock

En dat van die timestamps.. Die kun je gewoon aflezen van de creatie tijd van je lock. Je script zou idd aan de hand van de datum/tijd van een bestaand lock bestand jouw kunnen mailen oid. Maar dit hangt nogal af van wat je eigen procedures hierin zijn en welke functies in het script worden aangeroepen.

De taak alsnog uitvoeren kan trouwens erg gevaarlijk zijn, vooral bij systeemen met ripple backups of tape-backups.

[ Voor 21% gewijzigd door BCC op 13-06-2006 13:19 ]

[Wilke]

Bestandje maken:

touch /tmp/whatever

Testing of 'ie bestaat (in bash):

code:

if [ -e /tmp/whatever ]; then
  ....backupscript
fi

Zie 'man test' voor wat je tussen die if-blokhaken allemaal kunt neerzetten.

[ge-flopt]

en aan het eind wel weghalen natuurlijk

[Zeezicht]

En dan zet iemand in je /tmp een lock bestandje en je backup draait niet meer. Ik zou het in /var/run oid zetten, indien je de rechten hebt.

[BCC]

Ja.. je weet in principe nooit wanneer temp opgeruimd daat worden dus daar lijkt me niet handig. Dir waar ook je scriptje draait is ook handig als je de lock file wil terug vinden

[Gertjan]

BCC schreef op dinsdag 13 juni 2006 @ 15:59:
Ja.. je weet in principe nooit wanneer temp opgeruimd daat worden dus daar lijkt me niet handig. Dir waar ook je scriptje draait is ook handig als je de lock file wil terug vinden

Als jij 'nooit weet wanneer /tmp opgeruimd wordt' zou ik nog maar eens kijken naar /etc/init.d/bootclean.sh (op debian). Het zou niet best zijn als er een of andere functie was die op random tijdstippen je tmp-directories leeg gooide :-).