Puncte:0

crontab nu reușește să scrie jurnalele

drapel cn

Folosesc crontab pentru a rula un script Python în fiecare minut. Iată cum arată fișierul meu crontab:

*/1 * * * * sursă /root/.bashrc && sursă /home/env/bin/activate && python /home/manage.py shell < /home/script.py >> /var/log/navjob.log 2 >&1

Când încercați să verificați rezultatul cron în syslog cu această comandă #grep CRON /var/log/syslog ieșirea este așa:

...CRON[764888]: (rădăcină) CMD (sursă /root/.bashrc && sursă /home/env/bin/activate && python /home/manage.py shell < /home/script.py >> /var/ log/navjob.log 2>&1)
...CRON[764887]: (CRON) informații (Fără MTA instalat, renunțarea la ieșire)

Dar fișierul jurnal (/var/log/navjob.log) este gol și codul nu este rulat!

Puncte:2
drapel hr

Când înlănțuiți comenzi și adăugați redirecționare, cum ar fi

cmd1 && cmd2 && cmd3 >> un fișier 2>&1

(sau cmd1; cmd2; cmd3 >> un fișier 2>&1 etc.) redirecționările se aplică numai ultimei comenzi din lanț. Pentru a le redirecționa pe toate, trebuie să grupați comenzile ca

{ cmd1 && cmd2 && cmd3 ; } >> un fișier 2>&1

sau (cu o subshell)

( cmd1 && cmd2 && cmd3 ) >> un fișier 2>&1

În acest caz, jobul tău cron este probabil să eșueze din prima sursă comanda, din moment ce sursă este un bashism și shell-ul implicit al lui cron este /bin/sh - fie adauga SHELL=/bin/bash înainte de intrarea crontab sau modificați sursă la POSIX .

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.