linux - CronJob niet actief

Ik heb als volgt een cronjob voor root-gebruiker in ubuntu-omgeving ingesteld door crontab -e

te typen

 34 11 * * * sh /srv/www/live/CronJobs/daily.sh
  0 08 * * 2 sh /srv/www/live/CronJobs/weekly.sh
  0 08 1 * * sh /srv/www/live/CronJobs/monthly.sh

Maar de cronjob wordt niet uitgevoerd. Ik heb geprobeerd te controleren of de cronjob wordt uitgevoerd met behulp van pgrep cronen dat geeft proces-id 3033. Het shellscript roept een python-bestand aan en wordt gebruikt om een e-mail te verzenden. Het uitvoeren van het python-bestand is ok. Er zit geen fout in, maar de cron wordt niet uitgevoerd. Het daily.sh-bestand bevat de volgende code.

python /srv/www/live/CronJobs/daily.py
python /srv/www/live/CronJobs/notification_email.py
python /srv/www/live/CronJobs/log_kpi.py

Antwoord 1, autoriteit 100%

WTF?! Mijn cronjob werkt niet?!

Hier is een checklist voor het debuggen van niet-draaiende cronjobs:

Is de Cron-daemon actief?

Voer ps ax | grep cronen zoek naar cron.
Debian: service cron startof service cron restart

Werkt cron?

* * * * * /bin/echo "cron works" >> /tmp/file
Syntaxis correct? Zie hieronder.
U moet uiteraard schrijftoegang hebben tot het bestand waarnaar u de uitvoer doorstuurt. Een unieke bestandsnaam in /tmpdie momenteel niet bestaat, moet altijd beschrijfbaar zijn.
Voeg waarschijnlijk ook 2>&1toe om zowel de standaardfout als de standaarduitvoer op te nemen, of voer de standaardfout afzonderlijk uit naar een ander bestand met 2>>/tmp/errors

Werkt de opdracht zelfstandig?

Controleer of het script een fout bevat door een test uit te voeren op de CLI
Test bij het testen van je commando als de gebruiker wiens crontab je aan het bewerken bent, wat misschien niet je login of root is

Kan cron uw taak uitvoeren?

Controleer /var/log/cron.logof /var/log/messagesop fouten.
Ubuntu: grep CRON /var/log/syslog
Redhat: /var/log/cron

Toestemmingen controleren

Stel uitvoerbare vlag in op het commando: chmod +x /var/www/app/cron/do-stuff.php
Als je de uitvoer van je opdracht omleidt naar een bestand, controleer dan of je toestemming hebt om naar dat bestand/de map te schrijven

Controleer paden

controleer she-bangs / hashbangs-regel
vertrouw niet op omgevingsvariabelen zoals PATH, omdat hun waarde onder cron waarschijnlijk niet hetzelfde zal zijn als onder een interactieve sessie

Onderdruk de uitvoer niet tijdens het debuggen

Vaak gebruikt is deze onderdrukking: 30 1 * * * command > /dev/null 2>&1
Schakel de standaarduitvoer of de standaardfoutmelding opnieuw in door >/dev/null 2>&1helemaal te verwijderen; of misschien doorverwijzen naar een bestand op een locatie waar u schrijftoegang hebt: >>cron.out 2>&1voegt standaarduitvoer en standaardfout toe aan cron.outin de thuismap van de aanroepende gebruiker.
Als je probeert te achterhalen waarom iets is mislukt, zijn de foutmeldingen zichtbaar in dit bestand. Lees het en begrijp het.

Werkt nog steeds niet? Hoera!

Verhoog het cron-foutopsporingsniveau

Debian
- in /etc/default/cron
- stel EXTRA_OPTS="-L 2"
- service cron restart
- tail -f /var/log/syslogom de uitgevoerde scripts te zien
Ubuntu
- in /etc/rsyslog.d/50-default.conf
- voeg toe aan of becommentarieer de regel cron.* /var/log/cron.log
- logger opnieuw laden sudo /etc/init.d/rsyslog restart
- voer cron opnieuw uit
- open /var/log/cron.log en zoek naar gedetailleerde foutmeldingen
Herinnering: deactiveer het logniveau als u klaar bent met debuggen

Voer cron uit en controleer de logbestanden opnieuw

Cronjob-syntaxis

# Minute  Hour  Day of Month      Month         Day of Week    User Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  
    0       2       *             *                *          root /usr/bin/find

Deze syntaxis is alleencorrect voor de root-gebruiker. De syntaxis van de crontab-gebruiker heeft het veld Gebruikerniet (gewone gebruikers mogen geen code uitvoeren zoals elke andere gebruiker);

# Minute  Hour  Day of Month      Month         Day of Week    Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  
    0       2       *             *                *          /usr/bin/find

Crontab-opdrachten

crontab -l
- Laat alle cron-taken van de gebruiker zien.
crontab -e, voor een specifieke gebruiker: crontab -e -u agentsmith
- Start de bewerkingssessie van je crontab-bestand.
- Als je de editor afsluit, wordt de aangepaste crontab automatisch geïnstalleerd.
crontab -r
- Verwijdert je crontab-item uit de cron-spooler, maar niet uit het crontab-bestand.

Antwoord 2, autoriteit 9%

Nog een reden waarom Crontab faalt: speciale afhandeling van de %teken.

Vanaf de handmatig bestand :

The entire command portion of the line, up to a newline or a
"%" character, will be executed by /bin/sh or by the shell specified
in the SHELL variable of the cronfile.  A "%" character in the
command, unless escaped with a backslash (\), will be changed into
newline characters, and all data after the first % will be sent to
the command as standard input.

In mijn specifieke geval gebruikte ik date --date="7 days ago" "+%Y-%m-%d"om parameters op mijn script te produceren, en het faalde stil. Ik heb eindelijk ontdekt wat er aan de hand was toen ik syslogcontroleerde en zag mijn opdracht is afgekapt op de %symbool. Je moet het zo ontsnappen:

date --date="7 days ago" "+\%Y-\%m-\%d"

Zie hier voor meer informatie:

http: // www. Ducea.com/2008/11/12/USING-the-character-in-crontab-Entries/

Antwoord 3, Autoriteit 6%

Ten slotte vond ik de oplossing. Hierna volgt de oplossing: –

Gebruik nooit relatieve pad in Python-scripts die via Crontab moeten worden uitgevoerd.
Ik heb in plaats daarvan zoiets gedaan: –

import os
import sys
import time, datetime
CLASS_PATH = '/srv/www/live/mainapp/classes'
SETTINGS_PATH = '/srv/www/live/foodtrade'
sys.path.insert(0, CLASS_PATH)
sys.path.insert(1,SETTINGS_PATH)
import other_py_files

SUT NOOIT DE CRONTAB-code Gebruik in plaats daarvan Mailserver en controleer de e-mail voor de gebruiker. Dat geeft duidelijkere inzichten van wat er gaat.

Antwoord 4, Autoriteit 3%

Ik wil 2 punten toevoegen die ik heb geleerd:

CRON Config-bestanden in /etc/cron.d/ mogen geen punt (.) bevatten. Anders zal het niet door Cron worden gelezen.
Als de gebruiker die uw opdracht uitvoert, is niet in / etc / schaduw. Het mag geen cron plannen.

Refs:

Antwoord 5

Om een ander punt toe te voegen, moet een bestand in /etc/cron.d aan het einde een lege nieuwe lijn bevatten. Dit is waarschijnlijk gerelateerd aan het antwoord van Luciano, wat specificeert dat:

The entire command portion of the line, up to a newline or a "%"
character, will be executed

Antwoord 6

Ik heb nog een reden gevonden voor de crontab van de gebruiker niet uitgevoerd: de hostnaam is niet aanwezig op het hosts-bestand:

user@ubuntu:~$ cat /etc/hostname
ubuntu

Nu het hosts-bestand:

user@ubuntu:~$ cat /etc/hosts
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Dit staat op een Ubuntu 14.04.3 LTS, de manier om het te repareren is toevoegen aan de hostnaam aan het hosts-bestand , zodat het lijkt op zoiets:

user@ubuntu:~$ cat /etc/hosts
127.0.0.1 ubuntu localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Antwoord 7

Voor mij was de oplossing dat het bestand dat cron probeerde uit te voeren zich in een versleutelde map bevond, meer bepaald een gebruikersmap op /home/. Hoewel de crontab als root was geconfigureerd, omdat het script dat werd uitgevoerd in een versleutelde gebruikersmap in /home/cron stond, kon deze map alleen worden gelezen als de gebruiker daadwerkelijk was ingelogd. Om te zien of de map versleuteld is, controleert u of deze map bestaat:

/home/.ecryptfs/<yourusername>

zo ja, dan heb je een versleutelde homedirectory.

De oplossing voor mij was om het script naar een niet=gecodeerde map te verplaatsen en alles werkte prima.

Antwoord 8

Ik vond nuttige foutopsporingsinformatie op een Ubuntu 16.04-server door het volgende uit te voeren:

systemctl status cron.service

In mijn geval werd ik vriendelijk geïnformeerd dat ik een opmerking ‘#’ had achtergelaten op een opmerkingsregel:

Aug 18 19:12:01 is-feb19 cron[14307]: Error: bad minute; while reading /etc/crontab
Aug 18 19:12:01 is-feb19 cron[14307]: (*system*) ERROR (Syntax error, this crontab file will be ignored)

Antwoord 9

Het kan ook een tijdzoneprobleem zijn.

Cron gebruikt de lokale tijd.

Voer het commando timedatectluit om de machinetijd te zien en zorg ervoor dat je crontab zich in dezelfde tijdzone bevindt.

https://askubuntu.com/a/536489/1043751

Antwoord 10

Er zijn al veel antwoorden, maar geen van hen heeft me geholpen, dus ik zal de mijne hier toevoegen voor het geval het nuttig is voor iemand anders.

In mijn situatie werkten mijn cronjobs totdat er een stroomtekort was dat de stroom naar mijn Raspberry Pi afsneed. Cron is beschadigd. Ik denk dat het een lang python-script aan het draaien was, precies toen het tekort zich voordeed. Niets in het hoofdantwoord hierboven werkte voor mij. De oplossing was echter vrij eenvoudig. Ik moest cron gewoon opnieuw installeren met:

sudo apt-get --reinstall install cron

Het werkt hierna meteen.

Antwoord 11

Ik ondervond hetzelfde probleem waarbij crons niet actief waren.
We hebben dit opgelost door de rechten en eigenaar te wijzigen door:
Crons maakten root-eigenaar zoals we hadden vermeld in crontab AND
Cronjobs 644 toestemming gegeven

Antwoord 12

Ik had een soortgelijk probleem als de onderstaande link.

vergelijkbaar met mijn probleem
mijn oorspronkelijke bericht

Mijn probleem

Mijn probleem was dat cron / crontab mijn bash-script niet zou uitvoeren. dat bash-script voerde een python-script uit.

origineel bash-bestand

#!/bin/bash
python /home/frosty/code/test_scripts/test.py

python-bestand (test.py)

from datetime import datetime
def main():
    dt_now = datetime.now()
    string_now = dt_now.strftime('%Y-%m-%d %H:%M:%S.%f')
    with open('./text_file.txt', 'a') as f:
        f.write(f'wrote at {string_now}\n')
    return None
if __name__ == '__main__':
    main()

de fout die ik kreeg

 File "/home/frosty/code/test_scripts/test.py", line 7
    string_to_write = f'wrote at {string_now}\n'
                                               ^
SyntaxError: invalid syntax

deze fout was niet logisch omdat de code foutloos werd uitgevoerd vanuit het bash-bestand en het python-bestand.

** Opmerking -> zorg ervoor dat u in het bestand crontab -ede uitvoer niet onderdrukt. Ik heb de uitvoer naar een bestand gestuurd door >>/path/to/cron/output/file.log 2>&1toe te voegen na het commando. hieronder is mijn crontab -e invoer

*/5 * * * * /home/frosty/code/test_scripts/echo_message_sh >>/home/frosty/code/test_scripts/cron_out.log 2>&1

het probleem

cron gebruikte de verkeerde python-interpreter, waarschijnlijk python 2 vanwege de syntaxisfout.

hoe ik het probleem heb opgelost

Ik heb mijn bash-bestand gewijzigd in het volgende

#!/bin/bash
conda_shell=/home/frosty/anaconda3/etc/profile.d/conda.sh
conda_env=base
source ${conda_shell}
conda activate ${conda_env}
python /home/frosty/code/test_scripts/test.py

En ik heb mijn python-bestand gewijzigd in het volgende

from datetime import datetime
def main():
    dt_now = datetime.now()
    string_now = dt_now.strftime('%Y-%m-%d %H:%M:%S.%f')
    string_file = '/home/frosty/code/test_scripts/text_file.txt'
    string_to_write = 'wrote at {}\n'.format(string_now)
    with open(string_file, 'a') as f:
        f.write(string_to_write)
    return None
if __name__ == '__main__':
    main()

Antwoord 13

Soms staat de opdracht die cron moet uitvoeren in een map waar cron geen toegang toe heeft, meestal op systemen waar de thuismappen van gebruikers 700 zijn en de opdracht zich in die map bevindt.

CronJob niet actief