---

Hejsa

Et simpelt spørgsmål som jeg kom til at tænke på mens jeg lavade et cron
script

Hvad sker der hvis cron scriptet tager længere tid at køre end der er
pause mellem dens aktiveringer f.eks. et cron script der kører hver time
tager 1.5 time om at køre.

Er cron smart nok til ikke at starte en ny kørsel hvis den gamle stadig
kører, eller starter den blindt en ny ?

mvh
henrik

---

Den Sun, 12 Nov 2006 02:02:50 +0100 skrev Henrik Lynggaard Hansen:
> Hejsa
>
> Et simpelt spørgsmål som jeg kom til at tænke på mens jeg lavade et cron
> script
>
> Hvad sker der hvis cron scriptet tager længere tid at køre end der er
> pause mellem dens aktiveringer f.eks. et cron script der kører hver time
> tager 1.5 time om at køre.
>
> Er cron smart nok til ikke at starte en ny kørsel hvis den gamle stadig
> kører, eller starter den blindt en ny ?

Det kommer an på hvilken cron du bruger. Jeg mindes at være stødt
på en hvor manualen nævnte at den IKKE ville blive startet igen, men
de fleste versioner gør mig bekendt bare som de får besked på uden
at forsøge at være klogere end administratoren.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

On Sun, 12 Nov 2006 01:06:51 +0000, Kent Friis wrote:

> Det kommer an på hvilken cron du bruger. Jeg mindes at være stødt
> på en hvor manualen nævnte at den IKKE ville blive startet igen, men
> de fleste versioner gør mig bekendt bare som de får besked på uden
> at forsøge at være klogere end administratoren.
>
Det sikreste, mig bekendt, hvis man har en sådan situation, er at oprette
en temp-fil, når skriftet starter, og fjerne den igen når scriptet er
færdigt. Hver gang scriptet starter, udføres følgende test:

if [ -f /tmp/temp-fil ]; then
exit 1
fi

touch /tmp/temp-fil

.......

rm -f /tmp/temp-fil
exit 0

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

2006-11-12 Michael Rasmussen wrote
> On Sun, 12 Nov 2006 01:06:51 +0000, Kent Friis wrote:
>
>> Det kommer an på hvilken cron du bruger. Jeg mindes at være stødt
>> på en hvor manualen nævnte at den IKKE ville blive startet igen, men
>> de fleste versioner gør mig bekendt bare som de får besked på uden
>> at forsøge at være klogere end administratoren.
>>
> Det sikreste, mig bekendt, hvis man har en sådan situation, er at oprette
> en temp-fil, når skriftet starter, og fjerne den igen når scriptet er
> færdigt. Hver gang scriptet starter, udføres følgende test:
>
> if [ -f /tmp/temp-fil ]; then
> exit 1
> fi
>
> touch /tmp/temp-fil
>
> ......
>
> rm -f /tmp/temp-fil
> exit 0

Og den metoder forudsætter så at instans-1 når forbi test og touch inden
instans-2 bliver startet.

Den smukke løsning er at sikre at test og touch sker i en atomisk
operation.



/Morten

---

Morten Guldager wrote:

> Og den metoder forudsætter så at instans-1 når forbi test og touch inden
> instans-2 bliver startet.
>
> Den smukke løsning er at sikre at test og touch sker i en atomisk
> operation.

Men vel også lidt overkill når hvis der er en time mellem jobbene bliver
kaldt.(og det står først i scriptet) ?

mvh
henrik

---

Morten Guldager wrote:
> 2006-11-12 Michael Rasmussen wrote
>> On Sun, 12 Nov 2006 01:06:51 +0000, Kent Friis wrote:
>>
>>> Det kommer an på hvilken cron du bruger. Jeg mindes at være stødt
>>> på en hvor manualen nævnte at den IKKE ville blive startet igen, men
>>> de fleste versioner gør mig bekendt bare som de får besked på uden
>>> at forsøge at være klogere end administratoren.
>>>
>> Det sikreste, mig bekendt, hvis man har en sådan situation, er at oprette
>> en temp-fil, når skriftet starter, og fjerne den igen når scriptet er
>> færdigt. Hver gang scriptet starter, udføres følgende test:
>>
>> if [ -f /tmp/temp-fil ]; then
>> exit 1
>> fi
>>
>> touch /tmp/temp-fil
>>
>> ......
>>
>> rm -f /tmp/temp-fil
>> exit 0
>
> Og den metoder forudsætter så at instans-1 når forbi test og touch inden
> instans-2 bliver startet.
>
> Den smukke løsning er at sikre at test og touch sker i en atomisk
> operation.
>
Metoden er sikker nok, det samme job lægges da ikke til start i cron med
så korte mellemrum, at der ved normal afvikling er fare for kollision.
Metoden er effektiv, hvis et job, f.eks. pga. fejlprogrammering, bliver
hængende for længe, måske i en uendelig løkke. I værste fald kan et job,
der bliver hængende i en uendelig løkke, blive startet så mange, at
serveren bliver kvalt.
Hvad mener du med atomisk operation?. Kan du angive en anden løsning
end den beskrevne?.

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk
Registered Linux User #401007

---

>>>>> "JH" == Jørgen Heesche <heesche@webspeed.dk> writes:

JH> Kan du angive en anden løsning end den beskrevne?.

touch test # Vi skal bruge en fil
if ln test lockfil ; then
echo Jubii, vi fik låsen
...
rm lockfil
else
echo Trist
fi


/Benny

---

Benny Amorsen <benny+usenet@amorsen.dk> writes:

>>>>>> "JH" == Jørgen Heesche <heesche@webspeed.dk> writes:
>
> JH> Kan du angive en anden løsning end den beskrevne?.
>
> touch test # Vi skal bruge en fil
> if ln test lockfil ; then

Du kan ogsaa bare symlinke - evt. til $$, saa kan man ogsaa se
hvem der har laasen :)

--
Christian Joergensen | Linux, programming or web consultancy
http://www.razor.dk | Visit us at: http://www.gmta.info

---

>>>>> "CJ" == Christian Joergensen <mail@razor.dk> writes:

CJ> Du kan ogsaa bare symlinke - evt. til $$, saa kan man ogsaa se
CJ> hvem der har laasen :)

Det er rigtigt. Jeg kan bare godt lide ln til en fil i samme katalog.
Den og så unlink er de eneste rigtigt "atomiske" filsystems-kommandoer
på traditionel Unix. I dette tilfælde vil symlinks virke, fordi man
aldrig opdaterer et symlink, men kun laver det eller sletter det.

Hvis nu man vænner sig til symlinks, og f.eks. har et symlink, der
altid skal pege på enten den nye eller den gamle version. Så bruger
man ln -sf, og bam, pludselig er der et øjeblik, hvor symlinket ikke
eksisterer. GNU ln laver nemlig en unlink først, i stedet for at lave
en midlertidigt symlink efterfulgt at en hard link eller en rename.


/Benny

---

On 2006-11-12, Morten Guldager <Morten.Guldager@gmail.com> wrote:
> Den smukke løsning er at sikre at test og touch sker i en atomisk
> operation.

if ! mkdir $LOCKDIR
then
   echo "vi kører allerede"
   exit 0
fi

....



rmdir $LOCKDIR

---

I dk.edb.system.unix, skrev Sune Vuorela:
> On 2006-11-12, Morten Guldager <Morten.Guldager@gmail.com> wrote:
> > Den smukke løsning er at sikre at test og touch sker i en atomisk
> > operation.
>
> if ! mkdir $LOCKDIR
> then
>    echo "vi kører allerede"
>    exit 0
> fi
>

Hvis hvis programmet bliver kill'ed inden det når til rmdir? Hvornår
starter det næste så?
>
> rmdir $LOCKDIR

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

2006-11-12 Jesper Krogh wrote
> I dk.edb.system.unix, skrev Sune Vuorela:
>> On 2006-11-12, Morten Guldager <Morten.Guldager@gmail.com> wrote:
>> > Den smukke løsning er at sikre at test og touch sker i en atomisk
>> > operation.
>>
>> if ! mkdir $LOCKDIR
>> then
>>    echo "vi kører allerede"
>>    exit 0
>> fi
>>
>
> Hvis hvis programmet bliver kill'ed inden det når til rmdir? Hvornår
> starter det næste så?

Aldrig. ihvertfald ikke før sysadm har fjernet den hængende lås.

Men du har samme problem hvis et program går i stå uden at dø.


/Morten

---

I dk.edb.system.unix, skrev Morten Guldager:
> 2006-11-12 Jesper Krogh wrote
> > I dk.edb.system.unix, skrev Sune Vuorela:
> >> On 2006-11-12, Morten Guldager <Morten.Guldager@gmail.com> wrote:
> >> > Den smukke løsning er at sikre at test og touch sker i en atomisk
> >> > operation.
> >> if ! mkdir $LOCKDIR
> >> then
> >>    echo "vi kører allerede"
> >>    exit 0
> >> fi
> >
> > Hvis hvis programmet bliver kill'ed inden det når til rmdir? Hvornår
> > starter det næste så?
>
> Aldrig. ihvertfald ikke før sysadm har fjernet den hængende lås.
> Men du har samme problem hvis et program går i stå uden at dø.

Spørgsmålet var en smule retorisk.. Sørg for at lockdir er i /tmp og
/tmp bliver ryddet ved bootup, eller håndter denne situation på en anden
og bedre måde.. (skriv processid til en fil og lad programmet checkke om
det program der påstår at have låsen rent faktisk også har den).

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh skrev:

> Spørgsmålet var en smule retorisk.. Sørg for at lockdir er i
> /tmp og /tmp bliver ryddet ved bootup, eller håndter denne
> situation på en anden og bedre måde.

Man kan sætte en "trap" umiddelbart efter man har lavet kataloget:

#v+

   mkdir -p ${LOCKDIR} && \
    trap "rmdir ${LOCKDIR}" 0 1 2 3 15

#v-

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

I dk.edb.system.unix, skrev Klaus Alexander Seistrup:
> Jesper Krogh skrev:
>
> > Spørgsmålet var en smule retorisk.. Sørg for at lockdir er i
> > /tmp og /tmp bliver ryddet ved bootup, eller håndter denne
> > situation på en anden og bedre måde.
>
> Man kan sætte en "trap" umiddelbart efter man har lavet kataloget:
>
> #v+
>
>    mkdir -p ${LOCKDIR} && \
>     trap "rmdir ${LOCKDIR}" 0 1 2 3 15
>
> #v-

Det er abosolut bedre, det fanger de mest typiske ting.. så er der kun
situationen hvor strømmen bliver taget tilbage.

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:
> I dk.edb.system.unix, skrev Klaus Alexander Seistrup:
>> Jesper Krogh skrev:
>>
>>> Spørgsmålet var en smule retorisk.. Sørg for at lockdir er i
>>> /tmp og /tmp bliver ryddet ved bootup, eller håndter denne
>>> situation på en anden og bedre måde.
>> Man kan sætte en "trap" umiddelbart efter man har lavet kataloget:
>>
>> #v+
>>
>>    mkdir -p ${LOCKDIR} && \
>>     trap "rmdir ${LOCKDIR}" 0 1 2 3 15
>>
>> #v-
>
> Det er abosolut bedre, det fanger de mest typiske ting.. så er der kun
> situationen hvor strømmen bliver taget tilbage.
>
> Jesper
jeg har lige et tilægs spørgsmål, ang. cron.
hvordan gør jeg så et script starter hver halve tim kl 00 & 30 alle
timer året rundt.
er dette korekt?
00,30 * * * * komando

---

I dk.edb.system.unix, skrev andy:
> jeg har lige et tilægs spørgsmål, ang. cron.
> hvordan gør jeg så et script starter hver halve tim kl 00 & 30 alle
> timer året rundt.
> er dette korekt?
> 00,30 * * * * komando

Ja.. kig selv efter flere eksempler i "man 5 crontab".

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:
> I dk.edb.system.unix, skrev Morten Guldager:
>> 2006-11-12 Jesper Krogh wrote
>>> I dk.edb.system.unix, skrev Sune Vuorela:
>>>> On 2006-11-12, Morten Guldager <Morten.Guldager@gmail.com> wrote:
>>>>> Den smukke løsning er at sikre at test og touch sker i en atomisk
>>>>> operation.
>>>> if ! mkdir $LOCKDIR
>>>> then
>>>>    echo "vi kører allerede"
>>>>    exit 0
>>>> fi
>>> Hvis hvis programmet bliver kill'ed inden det når til rmdir? Hvornår
>>> starter det næste så?
>> Aldrig. ihvertfald ikke før sysadm har fjernet den hængende lås.
>> Men du har samme problem hvis et program går i stå uden at dø.
>
> Spørgsmålet var en smule retorisk.. Sørg for at lockdir er i /tmp og
> /tmp bliver ryddet ved bootup, eller håndter denne situation på en anden
> og bedre måde.. (skriv processid til en fil og lad programmet checkke om
> det program der påstår at have låsen rent faktisk også har den).
>
Hvorfor være i tvivl om hvilket program, der har sat en lockfil (eller
lockdir)?. Hvis et program giver lockfilen et unikt navn, kan der ikke
være tvivl om ejerskabet.

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk
Registered Linux User #401007

---

I dk.edb.system.unix, skrev Jørgen Heesche:
> > Spørgsmålet var en smule retorisk.. Sørg for at lockdir er i /tmp og
> > /tmp bliver ryddet ved bootup, eller håndter denne situation på en anden
> > og bedre måde.. (skriv processid til en fil og lad programmet checkke om
> > det program der påstår at have låsen rent faktisk også har den).
> >
> Hvorfor være i tvivl om hvilket program, der har sat en lockfil (eller
> lockdir)?. Hvis et program giver lockfilen et unikt navn, kan der ikke
> være tvivl om ejerskabet.

Jeg er heller ikke i tvivl om hvilket program det er.. men hvilken
instans af programmet det er.

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk