[DEBIAN] crontab probleem? geen output

[JaQ]

Ik zit met een beetje een wazig probleem met een crontab op een van de servers waar ik op werk:
Ik heb een script geschreven dat dagelijks een aantal "Failed" directories moet gaan monitoren, en als er 1 of meer bestanden in staan die automatisch gaat melden aan mij (via mail dus).

Dit script werkt (geen enkel probleem). Echter als ik dit in mijn user-crontab zet (ik heb geen root access, dus dit zal moeten) wordt het niet opgepakt door de cron.

crontabregel:
44 15 * * * /home/jl/failed_monitor.sh > /home/jl/bla.log 2>&1
Ik krijg echter totaal geen output (zelfs niet in bla.log).

Vervolgens denk ik: dan maar eens mijn cron testen:
49 15 * * * echo bla > /var/tmp/bla.log 2>&1

wederom geen logbestand. Bizar dus.

De cron draaid wel (als ik ps -ef | grep cron doe, zie ik dat /usr/sbin/cron als proces draaid (als root), echter aangezien ik geen root-access heb kan ik dit script niet in de system cron zetten.

Heeft iemand een i.d. waar dit aan kan liggen?

[deadinspace]

Staat er in je crontab wel een enter achter de laatste regel (met je commando)? Als die enter er niet staat negeert cron die regel namelijk (beetje irri dat hij daar niks over zegt).

[JaQ]

ik had er geen enter achter staan (dus laatste regel leeg), maar blijkbaar krijg ik nog steeds geen output (zal dat nog doortesten).

Zou het nog ergens anders aan kunnen liggen?

[Verwijderd]

Op vrijdag 10 mei 2002 17:07 schreef DrFrankenstoner het volgende:

ik had er geen enter achter staan (dus laatste regel leeg), maar blijkbaar krijg ik nog steeds geen output (zal dat nog doortesten).



Zou het nog ergens anders aan kunnen liggen?

Hoe zit het met het path van de user in zo'n cron task
Je gaat er nu van uit dat bash gedraait wordt om dat
script uit te voeren. Maar werkt dat wel zo?
Voeg aan je cron commandoregel eens de shell toe.
Dus zoiets als /bin/bash /home/user/xxx/do_it.sh
Of is dit niet nodig?

Z.

[Insanergy]

Hoe heb je je crontab geedit?
crontab -e?

[_JGC_]

Cron wel opnieuw gestart?

/etc/init.d/cron<tab> restart

Doe ik altijd wel als ik /etc/crontab aanpas met nano.

[Seth4Chaos]

Op vrijdag 10 mei 2002 19:48 schreef _JGC_ het volgende:
Cron wel opnieuw gestart?

/etc/init.d/cron<tab> restart

Doe ik altijd wel als ik /etc/crontab aanpas met nano.

Juistem en dat mag je als niet-root...dacht ut niet he

maareh mischien moet je ff kijken in /etc/cron.allow en /etc/cron.deny.
als cron.deny bestaat en je username staat erin kan je het wel vergeten, als cron.allow bestaat (en cron.deny niet) en jouw usernaam staat niet in cron.allow worden jouw commando's ook niet uitgevoerd. Als ze geen van beide bestaan heeft alleen de root toegang tot de cron.
kortom als je username niet in cron.allow staat moet je toch ff contact opnemen met de root en hem ff vriendelijk vragen of die jouw wil toevoegen.

verder kan je met de volgende regel ff goed testen of jouw cron jobs wel of niet worden uitgevoerd
* * * * * touch ~/.blabla

[deadinspace]

Op zaterdag 11 mei 2002 01:02 schreef Seth4Chaos het volgende:
Juistem en dat mag je als niet-root...dacht ut niet he

Hoeft ook niet. Als je je crontab edit met crontab -e dan wordt dat automatisch doorgegeven aan cron.

[JaQ]

toch maar weer even omhoog schoppen... (ik kon dit weekend niet bij die server).

Omgevingsvariabelen zouden inderdaad een optie kunnen zijn.. MAAR, een cronbestand begint toch altijd met SHELL=/bin/sh (of ksh of bash, afhankelijk van de shell).

Verder is een PATH variable inderdaad wijs (zoiets als PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin)

Maar dat is niet datgene wat er mis is (dat heb ik namelijk in mijn cron staan).

Uiteraard heb ik mijn crontab ge-edit met crontab -e (vi /etc/crontab zou volgens mij toch wel een permission error tijdens het schrijven opleveren, daarnaast is het ook nog eens onzettend vies).

Het opnieuw opstarten van de cron zonder root wordt inderdaad spannend.. (of is er een apparte cron-deamon voor een user-cron, die misschien wel appart door mij her / gestart moet worden?)

Voor het aan-te-roepen script gebruik ik het complete path (dus /home/<<username>>/<<scriptname>>.sh ) het script heeft de toevoeging .sh in de bestandsnaam (zonder .sh schijnt soms ook binnen debian problemen te geven, volgens google)

Hoe dan ook... errug vaag...