Cron işleri nasıl kaydedilir?

Her yürütmede cron işlerinin tam olarak ne yaptığını nasıl görebileceğimi bilmek istiyorum. Günlük dosyaları nerede bulunur? Veya çıktıyı e-postama gönderebilir miyim? Cron işi çalıştığında günlüğü göndermek için e-posta adresini ayarladım ancak henüz hiçbir şey almadım.

* * * * * myjob.sh >> /var/log/myjob.log 2>&1

cron işindeki tüm çıktıları /var/log/myjob.log dosyasına kaydeder

mailE-posta göndermek için kullanabilirsiniz . Çoğu sistem, işlenmemiş croniş çıktısını kök veya ilgili kullanıcıya e-posta ile gönderir .

Varsayılan olarak cron, / var / log / syslog dosyasına günlüğe kaydeder, böylece cron ile ilgili girdileri aşağıdakileri kullanarak görebilirsiniz:

grep CRON /var/log/syslog

/ubuntu/56683/where-is-the-cron-crontab-log

İşte benim kod:

* * * * * your_script_fullpath >> your_log_path 2>&1

En az üç farklı günlük kaydı türü vardır:

1. Programdan ÖNCE günlüğe kaydetme yürütülür; bu, yalnızca cronjob TRIED komutunu yürütmek için günlüğe kaydeder. Bu, @Matthew Lock tarafından belirtildiği gibi / var / log / syslog içinde bulunur.

2. @Spliffster tarafından belirtildiği gibi, bir e-postaya veya bir dosyaya gönderilebilen program SONRASI hataların günlüğe kaydedilmesi. Bir dosyaya giriş yapmayı tercih ederim, çünkü e-posta ile YENİ bir sorun kaynağınız ve e-posta gönderme ve alımının mükemmel çalışıp çalışmadığını kontrol edin. Bazen öyle, bazen değil. Örneğin, bir smtp'yi yapılandırmak istemediğiniz basit bir ortak masaüstü makinesinde, bazen bir dosyaya oturum açmayı tercih edersiniz:

    * * * *  COMMAND_ABSOLUTE_PATH > /ABSOLUTE_PATH_TO_LOG 2>&1
   

   • Ayrıca / ABSOLUTE_PATH_TO_LOG izinlerini kontrol etmeyi ve bu kullanıcının izinlerinden komutu çalıştırmayı düşünürüm. Sadece doğrulama için, bunun potansiyel bir sorun kaynağı olup olmadığını test ederken.
3. Programın kendi günlüğü, kendi hata işleme ve izleme amaçları için günlüğe kaydetme ile.

Cronjobs ile ilgili bazı yaygın sorun kaynakları vardır: * Yürütülecek ikilinin ABSOLUTE PATH. Kabuğunuzdan çalıştırdığınızda, işe yarayabilir, ancak cron işlemi başka bir ortam kullanıyor gibi görünür ve bu nedenle mutlak yolu kullanmazsanız her zaman ikili dosyaları bulamaz. * Bir ikili tarafından kullanılan KÜTÜPHANELER. Bu önceki noktanın aşağı yukarı aynıdır, ancak komutun NAME öğesini koyarsanız, tam olarak aynı kütüphaneyi kullanan ikili dosyaya başvuruyorsa veya daha iyisi, mutlak yolla bahsettiğiniz ikili dosyanın olup olmadığını kontrol edin. doğrudan konsolu kullandığınızda bahsettiğinizle aynıdır. İkili dosyalar locate komutu kullanılarak bulunabilir, örneğin:

$locate python

Yönlendireceğiniz ikili dosyanın, kabuğunuzda aradığınız ikili ile aynı olduğundan emin olun veya cronjob'a koymayı planladığınız mutlak yolu kullanarak kabuğunuzda tekrar test edin.

• Bir diğer yaygın sorun kaynağı da cronjob'daki sözdizimidir. Listeler (virgüller), aralıkları (tire -) tanımlamak, aralıkları (eğik çizgiler) vb. Tanımlamak için kullanabileceğiniz özel karakterler olduğunu unutmayın. Bir göz atın: http://www.softpanorama.org/Utilities/ cron.shtml

Ubuntu'da bir cron.logdosyayı yalnızca CRON girdilerini içerecek şekilde etkinleştirebilirsiniz .

Bahseder satırı yorumsuz croniçinde /etc/rsyslog.d/50-default.confdosyanın:

#  Default rules for rsyslog.
#

#                       For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                          /var/log/cron.log

Dosyayı kaydedip kapatın ve rsysloghizmeti yeniden başlatın :

sudo systemctl restart rsyslog

Artık cron günlük girdilerini kendi dosyasında görebilirsiniz:

sudo tail -f /var/log/cron.log

Örnek çıktılar:

Jul 18 07:05:01 machine-host-name CRON[13638]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

Ancak, gerçekte hangi komut dosyalarının çalıştırıldığı hakkında daha fazla bilgi görmezsiniz /etc/cron.dailyveya /etc/cron.hourlybu komut dosyaları çıktıyı doğrudan cron.log dosyasına (veya başka bir günlük dosyasına) yönlendirmezse.

Bir crontab'ın çalışıp çalışmadığını doğrulamak ve bunu aramak zorunda kalmayacaksanız cron.logveya syslogçıktıyı istediğiniz bir günlük dosyasına yönlendiren bir crontab oluşturun - şunun gibi:

# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
30 2 * * 1 /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log 2>&1

Alınan adımlar: https://www.cyberciti.biz/faq/howto-create-cron-log-file-to-log-crontab-logs-in-ubuntu-linux/

cron posta yoluyla çalıştırdığı her işin standart çıktısını ve standart hatasını zaten cron işinin sahibine gönderir.

Sen kullanabilirsiniz MAILTO=recipientiçinde crontabfarklı bir hesaba gönderilen e-postaların dosyası.

Bunun çalışması için, postanın düzgün bir şekilde çalışması gerekir. Yerel bir posta kutusuna teslim etmek genellikle bir sorun değildir (aslında, ls -l "$MAIL"zaten bazılarını aldığınız ortaya çıkacaktır) ancak kutunun dışına çıkıp internete çıkmak için MTA (Postfix, Sendmail, ne var) dünyaya bağlanmak için düzgün yapılandırılmış olmalıdır.

Çıktı yoksa, e-posta oluşturulmaz.

Yaygın bir düzenleme, çıktıyı bir dosyaya yönlendirmektir, bu durumda cron arka plan programı işin herhangi bir çıktı döndürdüğünü görmez. Bir varyant, standart çıktıyı bir dosyaya yeniden yönlendirmektir (veya komut dosyasını hiçbir şey yazdırmayacak şekilde yazabilir - belki de sonuçları bir veritabanında depolar veya herhangi bir şey çıktılamayan bakım görevleri gerçekleştirir?) Ve yalnızca varsa bir e-posta alır bir hata mesajıdır.

Her iki çıkış akışını yeniden yönlendirmek için sözdizimi

42 17 * * * script >>stdout.log 2>>stderr.log

Üzerine >>yazmak yerine nasıl eklediğimizi (iki katına ) dikkat edin , böylece önceki iş çıktılarının yerini bir sonraki iş çıktısı alır.

Burada birçok yanıtta önerildiği gibi, her iki çıktı akışının da tek bir dosyaya gönderilmesini sağlayabilirsiniz; ikinci yönlendirmeyi 2>&1"standart hata gittiğinde standart hata gitmelidir" şeklinde değiştirin. (Ama bu uygulamayı özellikle desteklemiyorum. Standart çıktıda gerçekten bir şey beklemiyorsanız, ancak belki de senaryonuzdan çağrılan harici bir araçtan gelen bir şeyi gözden kaçırmış olmanız mantıklıdır.)

cronişler ana dizininizde çalışır, bu nedenle göreli dosya adları buna göre olmalıdır. Ana dizininizin dışında yazmak istiyorsanız, bu hedef dosyaya yazma erişiminiz olduğundan ayrı olarak emin olmanız gerekir.

Yaygın bir antipattern, her şeyi yeniden yönlendirmektir /dev/null(ve bir şey çalışmadığında neyin yanlış gittiğini anlamanıza yardımcı olması için Yığın Taşması'nı isteyin; ancak kayıp çıktıyı da göremeyiz!)

Betiğinizin içinden, düzenli çıktıyı (gerçek sonuçlar, ideal olarak makine tarafından okunabilir biçimde) ve tanılamayı (genellikle bir insan okuyucu için biçimlendirilmiş) ayrı tuttuğunuzdan emin olun. Bir kabuk komut dosyasında,

echo "$results"  # regular results go to stdout
echo "$0: something went wrong" >&2

Bazı platformlar (ve örneğin GNU Awk), dosya adını /dev/stderrhata iletileri için kullanmanıza izin verir , ancak bu düzgün taşınabilir değildir; Perl'de warnve diestandart hataya yazdırın; Python'da, yaz sys.stderrveya kullanma logging; Ruby'de deneyin $stderr.puts. Hata mesajlarının, tanılama mesajını üreten komut dosyasının adını nasıl içermesi gerektiğine de dikkat edin.

Sudo ile bir komut çalıştırıyorsanız, buna izin vermez. Sudo'nun bir tty'ye ihtiyacı var.

Cron işlerinizi hala kontrol etmek istiyorsanız, cPanel'de Cron işlerini ayarlarken geçerli bir e-posta hesabı sağlamalısınız.

Geçerli bir e-posta belirttiğinizde, yürütülen cron işinin çıktısını alırsınız. Böylece kontrol edebilir ve her şeyin doğru bir şekilde yürütüldüğünden emin olabilirsiniz. Cron job komutundan çıktı yoksa e-posta almayacağınızı unutmayın.

Yürütülen her cron işi için bir e-posta alacağınızı lütfen unutmayın. Bu, crons'larınızın çok sık çalışması durumunda gelen kutunuzu doldurabilir