Neden crontab betikleri çalışmıyor?

452

Çoğu zaman, crontab komut dosyası, planlanan veya beklendiği gibi yürütülmez. Bunun için sayısız neden var:

  1. yanlış crontab notasyonu
  2. izin sorunu
  3. ortam değişkenleri

Bu topluluk vikisi, beklenen crontab komut dosyasının beklenmedik şekilde yürütülmemesi için en önemli nedenleri bir araya getirmeyi amaçlamaktadır. Her bir sebebi ayrı bir cevap olarak yazın.

Lütfen her bir yanıt için bir neden ekleyin - neden yapılmadığı ile ilgili ayrıntılar - ve bu nedenlerden dolayı düzeltin (ler).

Lütfen yalnızca cron'a özgü sorunları yazın, ör. kabuktan beklendiği gibi çalıştırılan ancak hatalı olarak cron tarafından yürütülen komutlar.

    
sordu Adam Matan 08.05.2017 20:15

46 cevap

430

Farklı ortam

Cron, işinize minimum bir dizi çevre değişkenini aktarır. Farkı görmek için, böyle bir kukla iş ekleyin:

* * * * * env > /tmp/env.output

/tmp/env.output 'nin oluşturulmasını bekleyin, ardından işi tekrar kaldırın. Şimdi, /tmp/env.output içeriğini, normal terminalinizde env çalışmasıyla karşılaştırınız.

Burada ortak bir "gotcha", PATH ortam değişkeninin farklı olmasıdır. Belki de cron komut dosyanız somecommand dizininde bulunan /opt/someApp/bin komutunu kullanır; PATH 'ye /etc/environment ' de eklediniz? cron bu dosyadaki PATH değerini yok sayar, bu nedenle cron'unuzda çalıştırdığınızda somecommand betnning runnning başarısız olur, ancak bir terminalde çalıştırıldığında çalışır. % Co_de% 'sinden gelen değişkenlerin cron işlerine aktarılacağını,% c_de% gibi kendisini sadece cron değişkenlerini değiştirmediğini belirtmek gerekir.

Bunu aşmak için komut dosyasının en üstünde kendi /etc/environment değişkenini ayarlamanız yeterlidir. Örn.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Bazıları yerine tüm komutlara mutlak yollar kullanmayı tercih eder. Buna karşı tavsiye ederim. Komut dosyanızı farklı bir sistem üzerinde çalıştırmak istiyorsanız ne olacağını düşünün ve bu sistemde, komut bunun yerine PATH dizinindedir. Komut dosyasının ilk satırında küçük bir düzenleme yapmak yerine PATH değerini /opt/someAppv2.2/bin ile değiştiren tüm komut dosyasını incelemeniz gerekir.

Ayrıca PATH değişkenini, tüm cron işlerine uygulanacak olan crontab dosyasına da ayarlayabilirsiniz. Örn.

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root
    
verilen cevap geirha 27.02.2018 19:47
287

En üstteki tutam: crontab dosyasının sonuna yeni satır eklemeyi unutursanız. Başka bir deyişle, crontab dosyası boş bir satırla bitmelidir.

Aşağıda, bu sorunla ilgili adam sayfalarındaki ilgili bölüm yer almaktadır ( man crontab sonra son verin):

   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)
    
verilen cevap user4124 02.02.2011 21:32
122

Cron daemon çalışmıyor. Birkaç ay önce bu işten bıktım.

Tür:

pgrep cron 

Sayı görmezseniz, cron çalışmıyor. sudo /etc/init.d/cron start , cron'u başlatmak için kullanılabilir.

DÜZENLEME: /etc/init.d aracılığıyla init komut dosyalarını çağırmak yerine, servisi kullanın yardımcı program, ör.

sudo service cron start
    
verilen cevap 4 revs, 4 users 38%user6019 26.01.2012 11:57
82

Komut dosyası dosya adları cron.d/ , cron.daily/ , cron.hourly/ , vb. içinde nokta içermemelidir ( . ), aksi halde çalışma bölümleri bunları atlayacaktır.

Çalışma parçalarını (8) inceleyin:

   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_-]+$).

Dolayısıyla, backup.sh , analyze-logs.pl dizininde cron.daily/ bir cron komut dosyanız varsa, uzantı adlarını kaldırmanız en iyisidir.

    
verilen cevap Xiè Jìléi 10.01.2017 16:20
55

Birçok ortamda, cron sh komutunu kullanarak komutları yürütürken, birçok kişi bash kullanacağını varsayar.

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

  • Çalışanın çalışıp çalışmadığını görmek için komutu sh 'de çalıştırmayı deneyin
  • Komutu bir bash alt kabuğunda, bash'ta çalıştırıldığından emin olmak için sarın:% bash -c "mybashcommand"
  • Cron'unuzu, crontab'ınızın tepesindeki kabuğu ayarlayarak bash içindeki 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
verilen cevap Ian Mackinnon 25.06.2011 21:30
34

Saat dilimleriyle ilgili bazı sorunlar yaşadım. Cron yeni kurulum zaman dilimi ile çalışıyordu. Çözüm, cron'u yeniden başlatmaktı:

sudo service cron restart
    
verilen cevap luissquall 07.02.2012 15:49
29

Crontab komutunuzun içinde % sembolü varsa, cron bunu yorumlamaya çalışır. Yani eğer % ile herhangi bir komut kullanıyor olsaydınız (tarih komutuna biçim belirtimi gibi) sizden kaçmanız gerekir.

Bu ve diğer iyi işler burada:
İşte

    
verilen cevap JMS 26.08.2012 08:59
28

Mutlak yol, komut dosyaları için kullanılmalıdır:

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

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

Bunun yerine:

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

Bu özellikle zor, çünkü aynı komut kabuktan yürütülürken çalışacaktır. Bunun nedeni, cron kullanıcısının, kullanıcıyla aynı PATH ortam değişkenine sahip olmamasıdır.

    
verilen cevap Adam Matan 24.01.2011 11:02
23

Ayrıca kullanıcının şifresinin süresinin dolması da mümkündür. Kökenin şifresinin bile geçerliliği biter. % Co_de% değerine sahip olabilirsiniz ve şifrenin süresi dolduğunda cron başarısız olduğunu görürsünüz. Bunu yaparak şifrenin asla sona ermeyeceğini ayarlayabilirsiniz: tail -f /var/log/cron.log

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

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

düzenlenmemiş ( passwd -x -1 <username> ) düzenlenmelidir:

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 logging etkinleştirme

Bazı sistemlerde (Ubuntu) cron için ayrı kayıt dosyası varsayılan olarak etkinleştirilmez, ancak syslog dosyasında cron ile ilgili günlükler görüntülenir. Biri kullanabilir

cat /var/log/syslog | grep cron

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

    
verilen cevap 6 revs, 5 users 34%unknown 11.05.2016 12:48
20

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

chmod +x /path/to/scrip dosyasını çalıştırarak komut dosyası çalıştırılabilir duruma gelir ve bu sorunu çözmelidir.

    
verilen cevap jet 26.01.2011 19:24
16

Eğer cronjob'niz GUI uygulamalarını çağırıyorsa, onlara hangi DISPLAY uygulamasını kullanmaları gerektiğini söylemeniz gerekir.

Örnek: Firefox fırlatma ile cron.

Komut dosyanızda export DISPLAY=:0 bir yer olmalıdır.

    
verilen cevap andrew 26.07.2012 17:46
14

İzin sorunları oldukça yaygındır, korkarım.

Yaygın bir geçici çözümün, her zaman root'un crontab'ını kullanarak yürütmesi gerektiğini unutmayın. Doğru izinleri ayarlamak kesinlikle büyük oranda gözden kaçan bir sorundur.

    
verilen cevap user9521 26.01.2011 16:53
13

Güvenli olmayan cron tablosu izni

Bir cron tablosu reddedildi izni güvensizse

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

Sorun

ile çözüldü
# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
    
verilen cevap John Peterson 15.06.2013 05:12
10

Komut, konuma duyarlı. Bu, her zaman bir komut dosyasında mutlak yollar kullanmakla ilgilidir, ancak aynı değildir. Cron işiniz, çalıştırmadan önce belirli bir dizine cd gereksinim duyabilir; Rails uygulamasında bir komisyon görevi, Rake'in uygun bir veritabanı yapılandırması, vb. değil, doğru görevi bulması için uygulama kökünde olması gerekebilir.

Yani bir crontab girişi

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

,

olarak daha iyi olurdu
23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production

Veya, crontab girişini daha basit ve daha az kırılgan tutmak için:

23 3 * * * /home/<user>/scripts/session-purge.sh

aşağıdaki kod /home/<user>/scripts/session-purge.sh ile:

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
    
verilen cevap pjmorse 29.11.2011 16:20
10

Bir crontab dosyasından diğerine geçtiğinde, geçmişte çalışan Crontab özellikleri kırılabilir. Bazen nedeni, bir sistem crontab dosyasından bir kullanıcı crontab dosyasına ya da tam tersi bir dosyaya aktardığınızdır.

Cron iş özellikleri formatı, kullanıcıların crontab dosyaları (/ var / spool / cron / kullanıcı adı veya / var / spool / cron / crontabs / kullanıcı adı) ve sistem crontabs ( /etc/crontab ve% co_de içindeki dosyalar) arasında farklılık gösterir. %).

Sistem crontabs komutları çalıştırmadan hemen önce ek bir 'kullanıcı' alanı var.

Bu, /etc/cron.d ya da george; command not found dosyasındaki bir dosyayı bir kullanıcının crontab dosyasına taşıdığınızda /etc/crontab gibi şeyler belirten hatalara neden olur.

Tersine, cron, /etc/cron.d gibi hatalar veya tersi gerçekleştiğinde benzerleri gönderir.

    
verilen cevap pbr 25.10.2013 17:04
9

cron betiği --verbose seçeneği ile bir komutu çağırıyor

Ben bir cron betiği başarısız oldu çünkü ben senaryoyu yazarken otomatik pilottaydım ve --verbose seçeneğini ekledim:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

Komut dosyası, kabuktan yürütülürken iyi sonuç verdi, ancak crontab'dan çalışırken başarısız oldu, çünkü gerçek çıktı, kabuktan çalıştırıldığında stdout'a gider, ancak crontab'tan çalıştırıldığında hiçbir yere varamaz. 'V' kaldırmak için kolay düzeltme:

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
    
verilen cevap Aaron Peart 03.06.2012 08:59
7

En sık rastlanan neden, hatalı bir şekilde belirtilen programda başarısız oldu. 11:15 için planlanan bir işi 30 23 * * * veya * * 11 15 * yerine 11 15 * * * olarak belirtmek gerekir. Gece yarısından sonraki işlerde haftanın günü de karıştığında M-F 2-6 'si gece yarısından sonra% co_de olur. Belirli tarihler genellikle nadiren kullandığımızdan genellikle bir problemdir 1-5 3 Mart değildir.

Farklı özellikteki çalışmalarınızda, zaman belirtimlerinde * * 3 1 * gibi desteklenmeyen seçenekler kullanılıyorsa, bu da hatalara neden olabilir. Bu çok kullanışlı bir seçenek ama evrensel olarak mevcut değil. Ayrıca, 2/3 veya 1-5 gibi listelerde yayınlanacak sorunlar var.

Niteliksiz yolların kullanılması da sorunlara neden oldu. Varsayılan yol genellikle 1,3,5 olur, bu nedenle yalnızca standart komutlar çalışır. Bu dizinlerde genellikle istenen komut yoktur. Bu, standart olmayan komutları kullanarak betikleri de etkiler. Diğer ortam değişkenleri de eksik olabilir.

Mevcut bir crontab 'ı tamamen gizlemek bana sorunlara neden oldu. Şimdi bir dosya kopyasından yüklüyorum. Bu, clobberlenmişse /bin:/usr/bin kullanarak mevcut crontab'dan kurtarılabilir. Crontab kopyasını ~ / bin olarak saklıyorum. Boyunca yorumlanır ve crontab -l satırı ile biter. Bu günlük bir crontab girişinden yeniden yüklenir:

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

Yukarıdaki yeniden yükleme komutu, crontab çalıştıran bir patlama yoluna sahip yürütülebilir bir crontab'a dayanır. Bazı sistemler, komutta çalışan crontab'ı ve dosyayı belirtmeyi gerektirir. Dizin ağ paylaşımlıysa, genellikle # EOF dosyasını dosya adı olarak kullanırım. Bu, yanlış sunucuya yanlış sunucuya yüklendiği durumlarda sonunda düzeltilecektir.

Dosyayı kullanmak, crontab'ın ne olması gerektiğinin bir yedeğini sağlar ve geçici düzenlemelerin ( crontab.$(hostname) kullanıyorum tek seferde) otomatik olarak yedeklenmesine izin verir. Programlama parametrelerini doğru bir şekilde almanıza yardımcı olan başlıklar mevcuttur. Deneyimsiz kullanıcılar bir crontab düzenlerken onları ekledim.

Nadiren, kullanıcı girişi gerektiren komutlara girdim. Bazıları giriş yönlendirmesiyle çalışsa da bunlar crontab altında başarısız olur.

    
verilen cevap BillThor 01.02.2011 19:37
6

SSH anahtarlarıyla bir hesaba erişiyorsanız, hesaba giriş yapmak mümkündür, ancak hesaptaki şifrenin kilitli olduğuna (örneğin, süresi dolan veya geçersiz şifre girişimlerine bağlı olarak) dikkat edin.

Sistem PAM kullanıyorsa ve hesap kilitliyse, bu işlem cronjob çalışmasını durdurabilir. (Bunu Solaris üzerinde test ettim, ama Ubuntu'da değil)

Bu gibi mesajları / var / adm / messages dizininde bulabilirsiniz:

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Yapmanız gereken tek şey çalıştırmak:

# passwd -u <USERNAME>

hesabı açmak için root olarak ve crontab yeniden çalışmalıdır.

    
verilen cevap JohnGH 24.10.2012 09:22
4

Böyle bir komutunuz varsa:

* * * * * /path/to/script >> /tmp/output

ve çalışmıyor ve herhangi bir çıktı göremiyorsunuz, bu mutlaka cron çalışmıyor anlamına gelebilir. Komut dosyası bozulabilir ve çıktı stderr 'e / tmp / output değerine aktarılmaz. Bu çıktıyı da yakalayarak durum böyle değil:

* * * * * /path/to/script >> /tmp/output 2>&1

bunun, sorununuzu yakalamanıza yardımcı olup olmadığını görmek için.

    
verilen cevap Philluminati 18.04.2018 20:26
3

=== Docker uyarısı ===

Docker kullanıyorsanız

Bence arka planda koşmak için cron yapmayı başaramadığımı eklemek doğru olur.

Konteynır içinde bir cron işi çalıştırmak için, amiri kullandım ve diğer işlemle birlikte cron -f çalıştırdım.

Düzenleme: Başka bir sorun - Kapsayıcıyı HOST ağ iletişimi ile çalışırken çalıştırmayı da başaramadım. Bu sorunu burada da görün: İşte

    
verilen cevap AlonL 20.05.2015 17:48
3

Benim durumumda cron ve crontab'ın farklı sahipleri vardı.

Çalışmıyordum:

[email protected] ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

Temel olarak cron-config'u çalıştırdım ve soruları doğru cevapladım. 'Kullanıcı' hesabım için Win7 kullanıcı şifremi girmem gereken bir nokta var. Yaptığım okumadan, bunun potansiyel bir güvenlik sorunu olduğu anlaşılıyor, ancak tek bir ev ağındaki tek yöneticiyim, bu yüzden tamam olduğuna karar verdim.

İşte beni yönlendiren komut sırası:

[email protected] ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to [email protected]
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


[email protected] ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

[email protected] ~ $
    
verilen cevap KiloOne 10.12.2015 10:20
3

Eski işlem verilerini bir veritabanından temizlemek için başka bir komut dosyası oluşturan bir yükleme kabuğu komut dosyası yazıyordum. Görevin bir parçası olarak, günlük cron işini, veritabanı yükü düşük olduğunda, rasgele bir zamanda çalışacak şekilde yapılandırmak zorunda kaldı.

Cron zamanlaması, kullanıcı adı ve ile mycronjob bir dosya oluşturdum & amp; komutu ve /etc/cron.d dizinine kopyalayın. Benim iki tuhaflarım:

  1. Çalıştırmak için mycronjob dosyasının köküne sahip olması gerekiyordu
  2. Dosyanın izinlerini 644 - 664 olarak ayarlamam gerekiyordu.

Bir izin sorunu, /var/log/syslog 'de aşağıdakine benzer bir şekilde görünecektir:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

İlk satır /etc/crontab dosyasına ve daha sonra /etc/cront.d altına yerleştirdiğim bir dosyaya başvuruyor.

    
verilen cevap Izik Golan 24.04.2017 21:53
2

crontab'ın bir şekilde yazılmış satırı anlamıyor. Doğru yazılmalı. İşte CrontabHowTo .

    
verilen cevap Kangarooo 02.02.2011 20:52
2

Cron daemon çalışıyor olabilir, ama aslında çalışmıyor. Cron'u yeniden başlatmayı deneyin:

sudo /etc/init.d/cron restart
    
verilen cevap Phil Dodd 25.11.2011 00:20
2

Bir satırdaki kullanıcı adı argümanı ile "crontab -e" üzerinden cron yazımı. Kullanıcıların (ya da sysadmins) kabuk betiklerini yazdıklarını ve neden otomatikleştirmediklerini anlamadıklarını gördüm. "User" argümanı / etc / crontab dosyasında var, ancak kullanıcı tanımlı dosyalar değil. Örneğin, kişisel dosyanız şöyle bir şey olurdu:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

/ etc / crontab şöyle olurdu:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Öyleyse neden bunu yapardın? Eh, izinlerinizi nasıl ayarlamak istediğinize bağlı olarak, bu çok kıvrık hale gelebilir. Karmaşıklıkları anlamayan ya da zorluklarla uğraşmak istemeyen kullanıcılar için görevleri otomatikleştirmek için komut dosyaları yazdım. İzinleri --x------ olarak ayarlayarak, komut dosyasını okuyabilmeleri (ve belki de yanlışlıkla değiştirebilmeleri) için yürütülebilir hale getirebilirim. Bununla birlikte, bu komutu birkaç dosyayla bir dosyadan çalıştırmak isteyebilirim (böylece daha kolay bir şekilde korunabilir), ancak dosya çıktısının doğru kullanıcı tarafından atanmış olduğundan emin olabilirsiniz. Bunu yapmak (en azından Ubuntu 10.10'da) hem dosyayı okuyamamayı hem de yürütmeyi başaramamayı ve / etc / crontab'da (örneğin, yeterli bir şekilde) hatalar yaşamadan hata vermemekle ilgili olarak yukarıda bahsedilen sorunu ihlal eder. co_de%).

Örnek olarak, root komut dosyasına sahip bir komut dosyasını çalıştırmak için kullanılan crontab -e örneklerini kabuk komut dosyasında karşılık gelen sudo crontab -e ile gördüm. Özensiz ama işe yarıyor. IMHO, daha zarif bir seçenek chown username file_output olarak kullanıcı adı ile bildirilmiş ve uygun izinler koymaktır, bu yüzden /etc/crontab doğru yere ve sahibine gider.

    
verilen cevap Mange 12.06.2012 19:42
2

Sağlam modda Aaron Peart'ın bahsettiği şeyden yola çıkarak, bazen bir komutun varsayılan davranışı, proc başladığında ekrana bir satır veya daha fazla bir çıktı vermekse, bazen ayrıntılı modda olmayan betikler başlayacak, ancak bitmeyecek. Örneğin, intranet için kullanılan ve uzaktaki sunuculara dosya yükleyen veya karşıya yükleyen bir yardımcı program olan intranet için bir yedekleme komut dosyası yazdım ve söz konusu uzak dosyalara yalnızca HTTP üzerinden erişebiliyorsanız oldukça kullanışlıdır. 'Curl İşte ', bir satırın ardından bir ilerleme çizgisi izlediği için asmak ve tamamlamam için yazdığım bir komut dosyasına neden oluyordu. Sessiz bayrağını (-s) herhangi bir bilgi vermemek için kullanmam gerekti ve dosya indirilemediyse işlemek için kendi koduma yazdım.

    
verilen cevap Mange 12.06.2012 22:06
2

Crontable'ınızdaki ortam değişkenlerini tanımlamanıza rağmen, bir kabuk komut dosyasında değilsiniz. Yani aşağıdaki gibi inşaatlar işe yaramaz:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Bunun nedeni değişkenlerin crontable olarak yorumlanmamasıdır: tüm değerler litterally. Ve parantezleri çıkarırsanız, bu aynıdır. Yani komutlarınız çalışmayacak ve günlük dosyalarınız yazılmayacak ...

Bunun yerine, tüm ortam değişkenlerinizi doğrudan tanımlamanız gerekir:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
    
verilen cevap Alexandre 07.06.2013 11:13
2

Bir görev cron içinde çalıştırıldığında, stdin kapalıdır. Stdin'in kullanılabilir olup olmadığına bağlı olarak farklı davranan programlar kabuk oturumu ile cron arasında farklı davranacaktır.

Bir örnek, web sunucusu günlük dosyalarını analiz etmek için goaccess programıdır. Bu cronda çalışmıyor:

goaccess -a -f /var/log/nginx/access.log > output.html

ve goaccess , raporu oluşturmak yerine yardım sayfasını gösterir. Kabukta bu

ile çoğaltılabilir
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

goaccess için düzeltme, kütükten okumak yerine stdin'den günlük okumasını sağlamaktır, böylece çözüm crontab girişini

olarak değiştirmektir.
cat /var/log/nginx/access.log | goaccess -a > output.html
    
verilen cevap Martijn de Milliano 09.08.2013 22:27
2

RHEL7 sunucularında, root cron işleri çalışır, ancak kullanıcı işleri işe yaramaz. Bir ev dizini olmadan işlerin işe yaramadığını gördüm (ancak / var / log / cron'da iyi hataları göreceksiniz). Ana dizini oluşturduğumda sorun çözüldü.

    
verilen cevap Dennis Parslow 02.02.2017 22:29
2

Eğer crontab dosyanızı bir editör kullanarak (samba ya da bir şeyle) düzenlediyseniz ve \ n \ r ya da \ r \ ile yeni satırları değiştirdiyseniz, cron çalışmayacaktır.

Ayrıca, eğer /etc/cron.d/* kullanıyorsanız ve bu dosyalardan birinde bir dosya varsa, cron dosyalar arasında ilerler ve kötü bir dosyaya bastığında duracaktır. Bu sorun olup olmadığından emin değil misiniz?

Kullanım:

od -c /etc/cron.d/* | grep \r
    
verilen cevap Doug 20.04.2017 03:38

Etiketlerdeki diğer soruları oku