Crontab komut dosyaları neden çalışmıyor?

Sık sık, crontab komut dosyaları zamanlamaya göre veya beklendiği gibi yürütülmez. Bunun birçok nedeni var:

  1. yanlış crontab gösterimi
  2. izinler sorunu
  3. ortam değişkenleri

Bu topluluk wiki, aşağıdakiler için en önemli nedenleri bir araya getirmeyi amaçlamaktadır crontab komut dosyaları beklendiği gibi yürütülmüyor. Her nedeni ayrı bir cevaba yazın.

Lütfen cevap başına bir neden ekleyin - neden yürütülmediğiyle ilgili ayrıntılar - ve bu nedenle düzeltin (düzeltin).

Gibi kabuğundan beklenen yürütmek ama yanlışlıkla cron ile çalıştırma cron sadece yaz lütfen belirli konularda, örneğin emrediyor.

Farklı ortam

Cron, işlerinize en az bir ortam değişkeni kümesi geçirir. Farkı görmek için, bunun gibi kukla bir iş ekleyin:

>* * * * * env /tmp/env.çıktı

Bekle /tmp/env.output oluşturulacak sonra işi yeniden kaldırın. Şimdi içeriğini karşılaştırın /tmp/env.output çıkışı ile env normal terminalinizde çalıştırın.

Burada ortak bir "yakaladım" PATH ortam değişkeni farklıdır. Belki cron betiğiniz komutu kullanır somecommand bulunan /opt/someApp/bin eklediğin PATH içinde /etc/environment? cron yok sayıyor PATH bu dosyadan, bu yüzden runnning somecommand komut dosyanızdan cron ile çalıştırıldığında başarısız olur, ancak bir terminalde çalıştırıldığında çalışır. Bu değişkenler fazlalaştı /etc/environment cron işlerine aktarılacak, sadece cron'un kendisini özel olarak belirlediği değişkenler değil, örneğin PATH.

Bunu aşmak için, sadece kendinizinkini ayarlayın PATH komut dosyasının en üstündeki değişken. Örneğin

#!/bin/bashPATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin# rest of script follows

Bazıları bunun yerine tüm komutlara mutlak yollar kullanmayı tercih eder. Buna karşı çıkmanızı tavsiye ederim. Komut dosyanızı farklı bir sistemde çalıştırmak istiyorsanız ne olacağını düşünün ve bu sistemde komut /opt/someAppv2.2/bin yerine. Tüm senaryoyu değiştirmen gerekecek. /opt/someApp/bin ile /opt/someAppv2.2/bin betiğin ilk satırında küçük bir düzenleme yapmak yerine.

PATH değişkenini, tüm cron işleri için geçerli olacak crontab dosyasında da ayarlayabilirsiniz. Örneğin

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin15 1 * * * backupscript --incremental /home /root

Benim üst gotcha: Eğer sonunda bir satırsonu eklemeyi unutursanız crontab dosya. Başka bir deyişle, crontab dosyası boş bir satırla bitmelidir.

Aşağıda, bu sorun için man sayfalarındaki ilgili bölüm bulunmaktadır (man crontab sonra sonuna atla):

   Although cron requires that each entry in a crontab end  in  a  newline   character,  neither the crontab command nor the cron daemon will detect   this error. Instead, the crontab will appear to load normally. However,   the  command  will  never  run.  The best choice is to ensure that your   crontab has a blank line at the end.   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Cron daemon çalışmıyor. Bunu birkaç ay önce gerçekten batırdım.

Tip:

pgrep cron 

Herhangi bir sayı görmüyorsanız (yani cron'un ana pıd'si), cron çalışmıyor demektir. sudo /etc/init.d/cron start cron'u başlatmak için kullanılabilir.

DÜZENLEME: /etc/init aracılığıyla init komut dosyalarını çağırmak yerine.d, kullanım serviceutility, örneğin

sudo service cron start

DÜZENLEME: Systemctl'yi modern Linux'ta da kullanabilirsiniz, örn.

sudo systemctl start cron

Komut dosyası dosya adları cron.d/, cron.daily/, cron.hourly/ vb., nokta içermemelidir (.), aksi takdirde çalışma parçaları onları atlayacaktır.

Bkz. çalıştırma parçaları (8):

   If neither the --lsbsysinit option nor the --regex option is given then   the names must consist entirely of upper and lower case  letters,  dig‐   its, underscores, and hyphens.   If  the  --lsbsysinit  option  is given, then the names must not end in   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to   one  or more of the following namespaces: the LANANA-assigned namespace   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace   (^[a-zA-Z0-9_-]+$).

Yani, bir cron betiğiniz varsa backup.sh, analyze-logs.pl içinde cron.daily/ dizin, uzantı adlarını kaldırmanız en iyisidir.

Birçok ortamda cron komutları kullanarak yürütür sh birçok kişi bunu kullanacağını varsayıyor olsa da bash.

Başarısız bir komut için bunu sınamak veya düzeltmek için öneriler:

  • Komutu çalıştırmayı deneyin sh çalışıp çalışmadığını görmek için :

    sh -c "mycommand"
  • Bash'de çalıştırıldığından emin olmak için komutu bir bash alt kabuğuna sarın:

    bash -c "mybashcommand"
  • Cron'a, kabuğunu crontab'ınızın en üstüne ayarlayarak bash'deki tüm komutları çalıştırmasını söyleyin:

    SHELL=/bin/bash
  • Komut bir komut dosyasıysa, komut dosyasının bir shebang içerdiğinden emin olun:

    #!/bin/bash

Saat dilimleriyle ilgili bazı sorunlarım vardı. Cron yeni yükleme saat dilimiyle çalışıyordu. Çözüm, cron'u yeniden başlatmaktı:

sudo service cron restart

Komut dosyaları için mutlak yol kullanılmalıdır:

Örneğin, /bin/grep bunun yerine kullanılmalıdır grep:

# m h  dom mon dow   command0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Yerine:

# m h  dom mon dow   command0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Bu özellikle zordur, çünkü aynı komut kabuktan çalıştırıldığında çalışacaktır. Nedeni cron aynı şey yok PATH kullanıcı olarak ortam değişkeni.

Crontab komutunuzda bir % içindeki sembol, cron onu yorumlamaya çalışır. Yani eğer bir komutla herhangi bir komut kullanıyor olsaydınız % içinde (tarih komutuna biçim belirtimi gibi) ondan kaçmanız gerekir.

Bu ve buradaki diğer iyi şeyler:
http://www.pantz.org/software/cron/croninfo.html

Cron yürütülebilir olmayan bir komut dosyası çağırıyor.

Koşarak chmod +x /path/to/script, komut dosyası yürütülebilir hale gelir ve bu, bu sorunu gidermelidir.

Kullanıcının şifresinin süresi dolmuş olması da mümkündür. Root'un şifresinin bile süresi dolabilir. Yapabilirsin tail -f /var/log/cron.log ve şifrenin süresi dolduğunda cron'un başarısız olduğunu göreceksiniz. Bunu yaparak parolayı hiçbir zaman sona ermeyecek şekilde ayarlayabilirsiniz: passwd -x -1 <username>

Bazı sistemlerde (Debian, Ubuntu) cron için günlüğe kaydetme varsayılan olarak etkin değildir. İçinde /etc/rsyslog.conf veya /etc/rsyslog.d/ 50-varsayılan.conf satır:

# cron.*                          /var/log/cron.log

düzenlenmelidir (sudo nano /etc/rsyslog.conf) uncommented için:

cron.*                          /var/log/cron.log

Bundan sonra, rsyslog'u yeniden başlatmanız gerekir

/etc/init.d/rsyslog restart

veya

service rsyslog restart 

Kaynak: Debian Linux'ta crontab oturum açmayı etkinleştirme

Bazı sistemlerde (Ubuntu) cron için ayrı günlük dosyası varsayılan olarak etkin değildir, ancak cron ile ilgili günlükler syslog dosyasında görünür. Biri kullanabilir

cat /var/log/syslog | grep cron -i

cron ile ilgili mesajları görüntülemek için.

Cron’un etkili olabilmesi için crontab -e'yi kapatmalısınız. Örneğin, vim kullanarak dosyayı düzenlerim ve yazmak için : wkullanırım, ancak ben de çıkana kadar iş cron'a eklenmez. Bu yüzden ben de: q` sonrasına kadar işi görmeyeceğim.

Cron’u hata ayıklamanın en iyi yolunun syslog’u kontrol etmek ve sorunları bulmak olduğunu düşünüyorum.

Benim durumumda - e-posta SPAM klasörüme gidiyordu, yani… hata ayıklama için saatler harcamadan önce bunu kontrol edin: D

Elektrik kesintileri

Lütfen bunu kontrol edin cron - Script doesn't run via crontab but works fine standalone - Ask Ubuntu