Neden crontab scriptleri çalışmıyor?

Genellikle, crontabkomut dosyaları zamanlamaya göre veya beklendiği gibi yürütülmez. Bunun çok sayıda nedeni var:

1. yanlış crontab notasyonu
2. izin sorunu
3. Ortam Değişkenleri

Bu topluluk wiki'si, crontabkomut dosyalarının beklendiği gibi yürütülmemesinin en önemli nedenlerini toplamayı hedefliyor . Her sebebi ayrı bir cevaba yazınız.

Lütfen her cevap için bir neden ekleyin - neden yürütülmediğinin ayrıntıları - ve bu nedenden dolayı düzeltin.

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

Farklı çevre

Cron, işinize en az sayıda ortam değişkeni kümesi iletir. Farkı görmek için, bunun gibi kukla bir iş ekleyin:

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

Bekleyin /tmp/env.output, oluşturulacak işi yeniden kaldırın. Şimdi normal terminalinizdeki çalışma /tmp/env.outputçıktısının içeriğini karşılaştırın env.

Burada ortak bir "gotcha", PATHortam değişkeninin farklı olmasıdır. Belki cron komut komutu kullanan somecommandbulunan /opt/someApp/binEğer eklediğiniz PATHiçinde /etc/environment? cron PATHbu dosyadan yok sayar , bu nedenle betiğinizden runnning somecommandcron ile çalıştırıldığında başarısız olur, ancak bir terminalde çalıştırıldığında çalışır. /etc/environmentGibi değişkenlerin cron işlerine aktarılacağına dikkat etmek önemlidir, sadece cron gibi kendi belirlediği değişkenleri değil PATH.

Bunu aşmak için PATH, betiğin en üstünde kendi değişkeninizi ayarlayın . Örneğin

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

# rest of script follows

Bazıları sadece tüm komutlara mutlak yollar kullanmayı tercih eder. Buna karşı öneriyorum. Komut dosyanızı farklı bir sistemde çalıştırmak istiyorsanız, /opt/someAppv2.2/binbunun yerine o komutun içinde olduğunu düşünün . Sen yerine tüm senaryonun geçmesi gerekirdi /opt/someApp/binile /opt/someAppv2.2/binyerine senaryonun ilk satırda küçük bir düzenlemeyi yapmanın.

PATH değişkenini, tüm cron işlerine uygulanacak crontab dosyasında da ayarlayabilirsiniz. Örneğin

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

15 1 * * * backupscript --incremental /home /root

Başa dön gotcha: crontabDosyanın sonuna yeni bir satır eklemeyi unutursanız . Başka bir deyişle, crontab dosyası boş bir satırla bitmelidir.

Aşağıda bu sayfadaki man sayfalarında ilgili bölüm bulunmaktadır ( man crontabdaha sonra sonuna atlayın):

   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 arka plan programı çalışmıyor. Birkaç ay önce bunu gerçekten mahvettim.

Tür:

pgrep cron 

Numara göremiyorsanız, cron çalışmıyor demektir. sudo /etc/init.d/cron startcron başlatmak için kullanılabilir.

EDIT: / bett / etc ile init betiklerini çağırmak yerine, servis programını kullanın, örneğin

sudo service cron start

EDIT: Ayrıca modern Linux'ta systemctl kullanabilirsiniz.

sudo systemctl start cron

Senaryo içinde filenames cron.d/, cron.daily/, cron.hourly/vb nokta (içermemelidir .aksi çalışma parçaları onları atlar).

Koşu parçalarına bakınız (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_-]+$).

Eğer bir cron komut dosyası var ise, backup.sh, analyze-logs.pliçinde cron.daily/dizinde, uzantı adlarını kaldırmak için en iyi olur.

Birçok ortamda cron komutları çalıştırır sh, birçok kişi kullanacağını varsayar bash.

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

• İşe yarayıp shyaramadığını görmek için komutu çalıştırmayı deneyin :

  sh -c "mycommand"
  

• Bash'da çalıştırıldığından emin olmak için komutu bir bash alt kabuğuna sarın:

  bash -c "mybashcommand"
  

• Cron'a, crontab'ınızın en üstündeki kabuğu ayarlayarak tüm komutları bash'de ç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ı problemlerim vardı. Cron, yeni kurulum zaman dilimi ile ç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/grepyerine kullanılmalıdır grep:

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

Onun yerine:

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

Bu özellikle zor, çünkü aynı komut kabuktan çalıştırıldığında çalışacak. Bunun nedeni, kullanıcı ile cronaynı PATHortam değişkenine sahip olmamasıdır .

Eğer crontab komutunuzda bir %sembol varsa, cron yorumlamaya çalışır. Bu nedenle, içinde herhangi bir komut kullanıyorsanız %(tarih komutuna format formatı gibi) atmanız gerekir.

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

Cron çalıştırılabilir olmayan bir betiği çağırıyor.

Çalıştırarak chmod +x /path/to/scripkomut çalıştırılabilir hale gelir ve bu sorunun çözülmesi gerekir.

Kullanıcı şifresinin süresi dolmuş da olabilir. Kökün bile şifresi sona erebilir. Yapabilirsiniz tail -f /var/log/cron.logve parolanın süresi ile cron başarısız göreceksiniz. Bu işlemi yaparak parolanın süresinin dolmamasını sağlayabilirsiniz:passwd -x -1 <username>

Bazı sistemlerde (Debian, Ubuntu) cron günlüğü varsayılan olarak etkin değildir. Gelen /etc/rsyslog.conf veya /etc/rsyslog.d/50-default.conf hat:

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

düzenlenmemiş ( sudo nano /etc/rsyslog.conf) olmalı :

cron.*                          /var/log/cron.log

Bundan sonra, rsyslog üzerinden yeniden başlatmanız gerekir.

/etc/init.d/rsyslog restart

veya

service rsyslog restart 

Kaynak: Debian Linux'ta crontab günlüğünü etkinleştir

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

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

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

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

Örnek: Firefox'un cron ile başlatılması.

Komut dosyanız bir export DISPLAY=:0yerde olmalı .

İzin problemleri oldukça yaygın, korkarım.

Ortak bir geçici çözümün, kökünün crontab komutunu kullanarak her şeyi yürütmek olduğunu, bazen Gerçekten Kötü Bir Fikir olduğunu unutmayın. Uygun izinlerin ayarlanması kesinlikle büyük ölçüde göz ardı edilen bir konudur.

Güvensiz cron tablosu izni

İzni güvensiz ise bir cron tablosu reddedilir

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 çözüldü

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

Komut dosyası konum duyarlıdır. Bu, her zaman bir komut dosyasında mutlak yollar kullanmakla ilgilidir, ancak tamamen aynı değildir. Çalıştırmadan cdönce cron işinizin belirli bir dizine gitmesi gerekebilir , örneğin Rails uygulamasındaki bir komisyon görevinin, uygun veritabanı yapılandırmasından bahsetmek yerine, doğru görevi bulmak için Rake için uygulama kökünde olması gerekebilir.

Yani bir crontab girişi

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

daha iyi olurdu

23 3 * * * cd / var / www / üretim / geçerli ve& / usr / bin / komisyon db: session_purge RAILS_ENV = üretim

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 ile /home/<user>/scripts/session-purge.sh:

cd / var / www / üretim / akım
/ usr / bin / rake db: session_purge RAILS_ENV = üretim

Geçmişte çalışan Crontab özellikleri , bir crontab dosyasından diğerine taşındığında bozulabilir. Bazen nedeni, spikeri bir sistem crontab dosyasından bir kullanıcı crontab dosyasına veya tam tersine taşımanızdır.

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

Sistem crontab'larının çalıştırma komutundan hemen önce fazladan bir 'kullanıcı' alanı vardır.

Bu, george; command not foundbir komutu /etc/crontabbir dosyadan çıkardığınızda veya bir dosyayı /etc/cron.dkullanıcının crontab dosyasına dönüştürdüğünüzde ortaya çıkan hataları belirtir .

Tersine, cron /usr/bin/restartxyz is not a valid username, tersi meydana geldiğinde benzer veya benzeri hatalar verir.

cron betiği --verbose seçeneğiyle bir komut çağırıyor

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

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

Betik kabuktan yürütülürken gayet iyi çalıştı, ancak verbose çıktısı kabuktan çalıştırıldığında stdout'a gittiğinden crontab'dan çalıştırırken başarısız oldu, ancak hiçbir yerde crontab'dan çalıştırılmadığı zaman. '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

Cron'u gördüğüm en sık neden yanlış belirtilen bir programda başarısız. Sanki 11:15 planlanan bir işi belirtmek için pratik ister 15 23 * * *yerine * * 11 15 *ya 11 15 * * *. Haftanın günü, gece yarısından sonraki işler için de karıştı. MF 2-6gece yarısından sonra değil 1-5. Belirli tarihler genellikle bir problemdir, çünkü nadiren kullanırız * * 3 1 *3 Mart değildir. Emin değilseniz, cron programlarınızı çevrimiçi olarak https://crontab.guru/ adresinden kontrol edin .

Farklı platformlarda çalışmanız durumunda 2/3zaman şartnameleri gibi desteklenmeyen seçenekler kullanılıyorsa arızalara da neden olabilirsiniz. Bu çok kullanışlı bir seçenektir, ancak evrensel olarak mevcut değildir. Ayrıca, 1-5ya da gibi listelerle ilgili sorunlara rastladım 1,3,5.

Niteliksiz yolları kullanmak da sorunlara neden oldu. Varsayılan yol genellikle genellikle /bin:/usr/binstandart komutlar çalışacak şekildedir. Bu dizinler genellikle istenen komuta sahip değildir. Bu, standart olmayan komutları kullanarak komut dosyalarını da etkiler. Diğer çevre değişkenleri de eksik olabilir.

Mevcut bir crontab'ı tamamen engellemek bana sorun çıkardı. Şimdi bir dosya kopyasından yüklüyorum. Bu, mevcut crontab'dan gizlenmişse kurtarılabilir crontab -l. Crontab kopyasını ~ / bin olarak saklıyorum. Baştan sona yorumlanır ve çizgi ile biter # EOF. Bu, aşağıdaki gibi bir crontab girişinden günlük olarak yeniden yüklenir:

#! / Usr / bin / crontab
# Bu crontab'ı yeniden yükle
#
54 12 * * * $ {HOME} / bin / crontab

Yukarıdaki yeniden yükleme komutu, crontab'ı çalıştıran bir patlama yolu olan yürütülebilir bir crontab'a dayanır. Bazı sistemler komutta crontab'ın çalışmasını ve dosyayı belirtmesini gerektirir. Dizin ağ paylaşımlıysa, genellikle crontab.$(hostname)dosyanın adı olarak kullanırım . Bu sonuçta yanlış crontab'ın yanlış sunucuya yüklendiği durumları düzeltir.

Dosyayı kullanmak, crontab'ın ne olması gerektiğinin bir yedeğini sağlar ve geçici düzenlemelerin (kullandığım tek zaman crontab -e) otomatik olarak yedeklenmesini sağlar. Çizelgeleme parametrelerini doğru almanıza yardımcı olan başlıklar vardır. Deneyimsiz kullanıcılar bir crontab düzenlerken, bunları ekledim.

Nadiren kullanıcı girişi gerektiren komutlarla karşılaştım. Bunlar crontab altında başarısız olur, ancak bazıları giriş yönlendirmesiyle çalışacaktır.

Bir hesaba SSH tuşları ile erişiyorsanız, hesapta oturum açmak mümkündür, ancak hesaptaki şifrenin kilitli olduğuna dikkat etmeyin (örn; süresi dolmuş veya geçersiz şifre denemeleri nedeniyle)

Sistem PAM kullanıyorsa ve hesap kilitliyse, bu cronjob'ın çalışmasını durdurabilir. (Bunu Solaris'te test ettim, ancak Ubuntu'da test etmedim)

Bunun gibi mesajları / var / adm / messages'de bulabilirsiniz:

24 Eki 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: cron, kilitli hesap myuser'ı yerel ana bilgisayardan doğrulamaya çalışıyor
24 Eki 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: cron, kilitli hesap myuser'ı yerel ana bilgisayardan doğrulamaya çalışıyor
24 Eki 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account: cron, kilitli hesap myuser'ı yerel ana bilgisayardan doğrulamaya çalışıyor
24 Ekim 07:54:00 mybox cron [29527]: [ID 731128 auth.notice] pam_unix_account: cron, kilitli hesap myuser'ı yerel ana bilgisayardan doğrulamaya çalışıyor

Tek yapmanız gereken koşmak:

# passwd -u <KULLANICI ADI>

Hesabın kilidini açmak için root olarak ve crontab'ın tekrar çalışması gerekir.

Eğer böyle bir komutunuz varsa:

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

ve çalışmıyor ve herhangi bir çıktı göremiyorsunuz, mutlaka cronun çalışmadığı anlamına gelmeyebilir. Komut dosyası bozulabilir ve çıktılar / tmp / çıktıya geçmeyen stderr öğesine gider. Bu çıktıyı da yakalayarak durumun böyle olmadığını kontrol edin:

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

Bunun sorununuzu çözmenize yardımcı olup olmadığını görmek için.

=== Docker uyarısı ===

Liman işçisi kullanıyorsanız,

Arka planda çalışacak cron yapmayı başaramadığımı eklemenin uygun olduğunu düşünüyorum.

Kabın içinde bir cron işi yürütmek için amir kullandım ve cron -fdiğer süreçle birlikte koştum .

Düzenleme: Başka bir sorun - Kapsayıcıyı HOST ağları ile çalıştırırken çalışmasını da sağlayamadım. Bu konuya ayrıca bakınız: https://github.com/phusion/baseimage-docker/issues/144

Eski işlem verilerini bir veritabanından temizlemek için başka bir komut dosyası oluşturan bir yükleme kabuğu betiği yazıyordum. Görevin bir parçası olarak günlük cronişi, veritabanı yükünün düşük olduğu zamanlarda, keyfi bir zamanda çalışacak şekilde yapılandırması gerekiyordu .

mycronjobCron programı, kullanıcı adı ve komut ile bir dosya oluşturdum ve /etc/cron.ddizine kopyaladım . İki yakaladım:

1. mycronjob Dosya çalıştırmak için kök tarafından sahiplenilmesi gerekiyordu
2. Dosyanın izinlerini 644 - 664 olarak çalışmak zorunda kalmayacak şekilde ayarlamak zorunda kaldım.

Bir izin sorunu /var/log/syslogşuna benzer bir şey olarak ortaya çıkacaktır :

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/crontabdosyaya ve daha sonra altına yerleştirdiğim dosyaya atıfta bulunur /etc/cront.d.

Crontab'ın bir şekilde yazdığı satır anlamıyor. Doğru yazılması gerekiyor. İşte CrontabHowTo .

Cron arka plan programı çalışıyor olabilir ama aslında çalışmıyor. Cron'u yeniden başlatmayı deneyin:

sudo /etc/init.d/cron restart

Cron'a "crontab -e" ile bir satırdaki kullanıcı adı argümanıyla yazılır. Kullanıcıların (veya sistem yöneticilerinin) kabuk komut dosyalarını yazarken ve neden otomatikleşemediklerini anlamadıklarını gördüm. "User" argümanı / etc / crontab içinde var, fakat kullanıcı tanımlı dosyalar değil. bu nedenle, örneğin kişisel dosyanız şöyle bir şey olurdu:

# m h dom mon dow command

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

Oysa / etc / crontab şöyle olacaktır:

# m h dom mon dow user   command

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

Peki neden ikincisini yapasın? Eh, izinlerinizi nasıl ayarlamak istediğinize bağlı olarak bu çok sarsılabilir. Karmaşıklıkları anlamayan veya angarya ile uğraşmak istemeyen kullanıcıların görevlerini otomatikleştirmek için komut dosyaları yazdım. İzinleri ayarlayarak --x------, komut dosyasını okuyabilmeleri için çalıştırılabilir hale getirebilirim (ve belki de yanlışlıkla değiştirebilirim). Bununla birlikte, bu komutu bir dosyadan başkaları ile birlikte çalıştırmak isteyebilirim (böylece bakımı kolaylaştırır) ancak dosya çıktısının doğru sahibine atandığından emin olun. (En azından Ubuntu 10.10 olarak) Bunu yapmak, dosyayı okumak yanı sıra yürütmek için yetersizlik, artı (geçerken tuhaf ki, hiçbir hataya neden olan / etc / crontab dönemleri koyarak ile yukarıda bahsedilen konuyla hem sonları crontab -e) .

Örnek olarak, sudo crontab -eroot betiğine karşılık gelen bir betiği root betiğinde çalıştırmak için kullanılan örnekleri gördüm chown username file_output. Özensiz, ama işe yarıyor. IMHO, Daha zarif seçenek /etc/crontabkullanıcı adı beyanı ve uygun izinlerle file_outputkoymak, doğru yere ve sahibine gidiyor.

Aaron Peart'ın ayrıntılı mod hakkında bahsettiği şeyi oluşturmak, bazen ayrıntılı modda olmayan komut dosyaları başlatacak ancak dahil edilen bir komutun varsayılan davranışı, işlem başladıktan sonra ekrana bir satır veya daha fazla çıktı verecekse bitmeyecektir. Örneğin, intranetimiz için, uzak sunuculara dosya yükleyen veya yükleyen bir yardımcı program olan curl'ı kullanan ve yalnızca söz konusu uzak dosyalara yalnızca HTTP üzerinden erişebiliyorsanız kullanışlıdır. 'Curl http://something.com/somefile.xls ' ifadesini kullanmak , yazdığım bir senaryoya neden oldu ve hiçbir zaman tamamlamadı, çünkü bir ilerleme çizgisinin ardından yeni bir satır attı. Sessiz bayrağını (-s) kullanarak herhangi bir bilgi çıktısını almamasını ve dosyanın indirilmemesi durumunda işlemek için kendi kodumu yazmam gerekti.

Çevresel değişkenleri crontable'da tanımlayabilseniz de, bir kabuk betiğinde değilsiniz. Yani aşağıdaki gibi yapılar 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'da yorumlanmamasıdır: tüm değerler litre olarak alınır. Ve parantezleri atlarsanız bu aynıdır. Yani komutlarınız çalışmaz ve günlük dosyalarınız yazılmaz ...

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}

Bir görev cron içinde çalıştırıldığında stdin kapanır. Stdin'in bulunup bulunmadığına bağlı olarak farklı davranan programlar, kabuk oturumu ile cron arasında farklı davranacaktır.

Bunun bir örneği, goaccessweb sunucusu günlük dosyalarını analiz etmek için kullanılan programdır . Bu cron içinde çalışmaz:

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

ve goaccessrapor 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

Bunun için düzeltme goaccess, dosyadan okumak yerine logu stdin'den okumasını sağlamaktır; bu nedenle çözüm crontab girişini değiştirmektir.

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

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

ÇALIŞTIRMAM Ben bu vardı:

User@Uva ~ $ 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 

Temelde cron-config çalıştırmalı ve soruları doğru cevaplamalıydım. 'Kullanıcı' hesabım için Win7 kullanıcı şifremi girmem gereken bir nokta var. Yaptığım okumadan, bu potansiyel bir güvenlik sorunu gibi görünüyor, ancak tek bir ev ağındaki tek yöneticiyim, bu yüzden tamam olduğuna karar verdim.

İşte beni yönlendiren komut dizisi:

User@Uva ~ $ 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 cygwin@cygwin.com.
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.


User@Uva ~ $ 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

User@Uva ~ $

RHEL7 sunucularımda kök cron işleri çalışacak, ancak kullanıcı işleri çalışmayacaktır. Bir ev dizini olmadan işlerin çalışmayacağını buldum (ancak / var / log / cron'da iyi hatalar göreceksiniz). Giriş dizinini oluşturduğumda sorun çözüldü.

Crontab dosyanızı bir windows editörü (samba veya başka bir şey kullanarak) kullanarak düzenlediyseniz ve yeni satırları \ n \ r veya sadece \ r ile değiştirdiyseniz, cron çalışmaz.

Ayrıca, /etc/cron.d/* kullanıyorsanız ve bu dosyalardan birinin içinde varsa, cron dosyalar arasında hareket edecek ve kötü bir dosyaya ulaştığında duracaktır. Sorunun bu olup olmadığından emin değil misin?

kullanın:

od -c /etc/cron.d/* | grep \r