Grundläggande problem med cron - löst med omstart av ubuntu

[Osprey]

Om cron borde ha "sparkat igång" jobbet så är det märkligt att den inte finns, annars är det fullt naturligt...

[dlundh]

min /var/log/syslog är full av såna här:
Nov 12 12:05:01 dlubuntu /USR/SBIN/CRON[6285]: (dlundh) CMD (/home/dlundh/vmstat.sh > /var/log/vmstat.log)


Men... den loggar inget och filen ~/done blir inte heller touchad. What gives?


Edit: nåväl, nu är det lunch.

[Osprey]

Jag funderar på om det kan vara så att det är smbmount som hänger sig så att reultatet blir en massa processer (zombies). Jag har haft liknande problem när jag försökt ha en process som bevakar antingen samba eller cifs vilket egentligen är samma sak numera när båda två blir cifs-monterade.

Prova att kommentera bort raden med smbmount och se vad som händer...

[dlundh]

Nope, även med smbmount utkommenterad är det samma symptom.
Ingen vmstat.log och filen ~/done är inte uppdaterad men jobbet ser ut att ha körts i syslog.

Djupt förbryllande.

Edit: Inga zombiepårocesser vad jag kan se med ps aux heller.

[Osprey]

Nämen vaditusan!! Nu provar jag och kör ditt script med samma entry i crontab här i min burk, så får vi se om det blir någon skillnad...

[Osprey]

Det fungerar helt klockrent här på min burk, men då kör jag det förstås "löst" utan ssh, smbmount, cp och rm eftersom jag inte har de filerna och burkarna här. Som det ser ut nu så skulle jag gissa att det är ssh som ballar ur/hänger sig hos dig...

Varför kör du förresten cp och rm istf mv?

[dlundh]

Har kommenterat ut ssh-bitarna nu och väntar på att det ska köras...


Angående användningen av mv vs. cp/rm - just nu är det akademiskt då scriptet av allt att döma inte körs men annars hade jag helt enkelt inte tänkt på mv.

[dlundh]

Nej, det funkar inte heller.
Ingenting i min crontab körs uppenbarligen, jag blir tokig på det här problemet.

Jag har gjort ett scrip nu som enbart gör följande:
#!/bin/bash

touch ~/done

Om inte ens det funkar vet jag faktiskt inte vad jag ska göra.

[dlundh]

Inte ens det funkar. Jag får väl göra något jag inte gjort på 14 dagar, 6 timmar och 17 minuter: starta om maskinen och se om det hjälper - Windows style.

[Osprey]

Omstart är endast den lates väg att på 5 minuter utföra något som kunde gjorts på 20 timmar...

Nåväl, utgående från nuläge:

1) Cron funkar och loggar i /var/log/syslog att den försöker köra scriptet.
2) Ingenting som scriptet ska göra verka hända.
3) Scriptet har ingenting som kan hänga sig.

Alltså: det verkar som om cron försöker köra scriptet men av någon anledning inte kan/får göra det...

Om det inte funkar nu så kolla i /var/log/syslog med "grep -i cron /var/log/syslog" och se om cron har kläckt ur sig något om att "livet är orättvist"...

[dlundh]

Problemet med att cron inte loggar något är att jag helt enkelt inte får skriva till /var/log, jag testade manuellt och det får min användare helt enkelt inte göra - eftersom jag inte ändrat några rättigheter på katalogen tänker jag inte heller göra det. Däremot loggar jag nu till mitt hembibliotek, så nu har jag goda förhoppningar om att få en logg.

...också har jag ju startat om också.

[Bowmore]

Har du provat att köra scriptet som root?
Kan tänka mig att t.ex monteringen mot ~/44 inte funkar då den väl pekar på /root/44 istället för /home/dlundh/44.

[dlundh]

Har du provat att köra scriptet som root?
Kan tänka mig att t.ex monteringen mot ~/44 inte funkar då den väl pekar på /root/44 istället för /home/dlundh/44.

Menar du att mina cron-jobb körs som root? Skulle inte det isåfall vara ett enormt säkerhetshål?

Med tanke på att logg-filerna nu skapas i mitt hembibliotek, av min användare, tror jag iaf att jobben körs med min användare, inte som root.

[Osprey]

Har du provat att köra scriptet som root?
Kan tänka mig att t.ex monteringen mot ~/44 inte funkar då den väl pekar på /root/44 istället för /home/dlundh/44.

Menar du att mina cron-jobb körs som root? Skulle inte det isåfall vara ett enormt säkerhetshål?

Med tanke på att logg-filerna nu skapas i mitt hembibliotek, av min användare, tror jag iaf att jobben körs med min användare, inte som root.

Kolla det genom att se om "done" finns i "/root"...

[dlundh]

Det verkar som om omstarten gjorde susen, nu körs scriptet och uppdaterar webbsidan som det ska. Jag skriver upp det här på listan över Windowsliknande beteende hos Ubuntu.

[Bowmore]

Menar du att mina cron-jobb körs som root? Skulle inte det isåfall vara ett enormt säkerhetshål?

Med tanke på att logg-filerna nu skapas i mitt hembibliotek, av min användare, tror jag iaf att jobben körs med min användare, inte som root.

Sorry, min "fula" ovana att köra cronjobb som root.
Så det löste sig med en omstart, jojo

[dlundh]

Menar du att mina cron-jobb körs som root? Skulle inte det isåfall vara ett enormt säkerhetshål?

Med tanke på att logg-filerna nu skapas i mitt hembibliotek, av min användare, tror jag iaf att jobben körs med min användare, inte som root.

Sorry, min "fula" ovana att köra cronjobb som root.
Så det löste sig med en omstart, jojo

Jag är lika förvånad som alla andra att en omstart gjorde susen. Jag har ju haft maximal otur, första gången någonsin jag lägger in ett cron-jobb fungerar det inte förrän jag startar om Ubuntu. Murphys lag etc. antar jag.

Nåja, jag lärde mig saker på vägen vilket ju alltid är positivt.

Tack till alla inblandade för all hjälp!

[Osprey]

förrän jag startar om Ubuntu. Murphys lag etc. antar jag.

Fel!! När det gäller operativsystem så är det den utökade varianten - Ballmers lag.

[Bowmore]

Kollade runt lite och tror att det är så att de olika crontab reggas vid uppstart, så har man ingen ~/.crontab när systemet startades senast så kommer den inte att köras förrän efter nästa omstart.

Misstanken kommer från denna wiki där det bl.a står:

The algorithm used by this cron is as follows:

1. On start-up, look for a file named .crontab in the home directories of all account holders.
2. For each crontab file found, determine the next time in the future that each command is to be run.
3. Place those commands on the Franta-Maly event list with their corresponding time and their "five field" time specifier.
4. Enter main loop:
1. Examine the task entry at the head of the queue, compute how far in the future it is to be run.
2. Sleep for that period of time.
3. On awakening and after verifying the correct time, execute the task at the head of the queue (in background) with the privileges of the user who created it.
4. Determine the next time in the future to run this command and place it back on the event list at that time value.

[Osprey]

Kollade runt lite och tror att det är så att de olika crontab reggas vid uppstart, så har man ingen ~/.crontab när systemet startades senast så kommer den inte att köras förrän efter nästa omstart.

Misstanken kommer från denna wiki där det bl.a står:

The algorithm used by this cron is as follows:

1. On start-up, look for a file named .crontab in the home directories of all account holders.
2. For each crontab file found, determine the next time in the future that each command is to be run.
3. Place those commands on the Franta-Maly event list with their corresponding time and their "five field" time specifier.
4. Enter main loop:
1. Examine the task entry at the head of the queue, compute how far in the future it is to be run.
2. Sleep for that period of time.
3. On awakening and after verifying the correct time, execute the task at the head of the queue (in background) with the privileges of the user who created it.
4. Determine the next time in the future to run this command and place it back on the event list at that time value.

Måste ju gälla endast under förutsättning att "crontab -e" inte körs, vilket innebär att crontab -e borde sparka till cron i häcken och säga till den att uppdatera. Om man däremot öppnar ~/.crontab direkt med vim eller annan editor så är det möjligt att inget sker förrän nästa omstart. Det som crontab -e gör är antagligen att öppna filen i editor, antingen "vi" eller vad som nu pekas ut av $EDITOR (eller något sådant har jag för mig) och när editeringen är avslutad så skickas en HUP till cron...