Soru:
Cron sorunu için varsayılan kabuk
cupakob
2012-10-10 13:02:53 UTC
view on stackexchange narkive permalink

Bazı komutlarım var, bash altında çalışıyorlar, ancak cronjob olarak değil. Sorunun nedenini görmek için, çıktıyı bir dosyaya kaydediyorum, işte örneğim: 

  51 * * * * source ~ / .rvm / scripts / rvm >> stack.log 2>&1

Günlük dosyasının içeriği: 

  / bin / sh: 1: kaynak: bulunamadı

Bu, cron'un bash içinde sh kullandığı anlamına gelir. Bunu /etc/crontab:

SHELL=/bin/bash
'de değiştirmeyi denedim

Ama bu çalışmıyor. / etc / passwd 'ye baktım ve burada daemon'un varsayılan kabuk olarak sh kullandığını görüyorum. Hem root hem de pi , varsayılan kabuk olarak bash 'a sahiptir. 

  root: x: 0: 0: root : / root: / bin / bashdaemon: x: 1: 1: daemon: / usr / sbin: / bin / shpi: x: 1000: 1000: ,,,: / home / pi: / bin / bash

cron için varsayılan kabuğunu değiştirmek için ne yapmalıyım? / etc / passwd içinde daemon kullanıcısı için / bin / bash ayarlamazdım ... imho bu iyi bir fikir değil.

düzenle:

  ls -l / bin / shlrwxrwxrwx 1 root root 4 Mar 30 2012 / bin / sh -> dash

burada /etc/crontab:

  # / etc / crontab: system-wide crontab: # Diğer crontab'lerin aksine çalıştırmanız gerekmeyen Bu dosyayı # ve /etc/cron.d'deki dosyaları düzenlediğinizde yeni sürümü yüklemek için `crontab '# komutu. Bu dosyalarda ayrıca kullanıcı adı alanları da vardır, # diğer crontab'lerin sahip olmadığı # SHELL = / bin / bashPATH = / usr / local / sbin: / usr / local / bin: / sbin: / bin: / usr / sbin: / usr / bin # mh dom mon dow user command17 * * * * root cd / && run-parts --report /etc/cron.hourly25 6 * * * root testi -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.daily)
47 6 * * 7 kök testi -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.weekly) 52 6 1 * * kök testi -x / usr / sbin / anacron || (cd / && run-parts --report /etc/cron.monthly) #
Neden crons ortamında "kaynak" yapmak istiyorsunuz? Basitçe "~ / .rvm / scripts / rvm" çalıştırmak işe yaramıyor mu? Ve bash olmayan ortamlarda ~ kullanımıyla ilgili sorunlarınız olabilir.
Dört yanıtlar:
Krzysztof Adamski
2012-10-10 13:07:33 UTC
view on stackexchange narkive permalink

Bu tür durumların çoğu (komut dosyasının kabukta çalıştığı ancak cron'da çalışmadığı), komut dosyasında farklı olan ortam değişkenlerinden kaynaklanır. Çoğu durumda problem PATH değişkenidir. Komut dosyasında çalıştırdığınız tüm yürütülebilir dosyalar için tam yolları kullanabilir veya komut dosyanızın ilk satırındaki PATH 'i değiştirebilirsiniz.

Bu tür sorunları izlemek için, aviable ortam değişkenlerinin dökümünden başlayabilirsiniz. env komutunu kullanarak komut dosyanıza şu şekilde ekleyin: / usr / bin / env> /tmp/env.txt

Komut dosyamda herhangi bir ortam değişkenim yok ... ve / bin / env mevcut değil.
Hayır, her zaman her kabukta bazı çevre değişkenlerine sahipsiniz. Bir örnek, daha önce bahsedilen "PATH" dir. Bunun yerine "/ usr / bin / env" ifadesini deneyin. Veya "env" util'e tam yolunuzun ne olduğunu kontrol etmek için "hangi ortam" ı kullanın.
Alex Chamberlain
2012-10-10 13:12:14 UTC
view on stackexchange narkive permalink

Kullanılan kabuk tire 'dir; bash 'den çok daha küçük ve daha kararlı olacak şekilde tasarlanmış POSIX uyumlu bir kabuk.

cron işleri yazmanız gerektiği tartışılabilir POSIX uyumlu olması. Alternatif olarak, mantığınızı bir komut dosyası içinde sarmalamayı ve shebang'i başa eklemeyi deneyin 

  #! / Usr / bin / env bash
neden #! / usr / bin / env bash ve #! / bin / bash değil? fark ne?
IMHO çok değil. Açıkçası, "bash" ın başka bir yerde saklanmasına izin verir. Bunu kim yapar, bilmiyorum!
Bunu da denedim ... Komutumu çağıran bir sarmalayıcı bash betiğim var, ancak bu da çalışmıyor. Ama / etc / crontab dosyasındaki değişikliklerin neden swich'i bash yapmadığına bakıyorum.
@cupakob `/ etc / crontab`ınızın tamamını lütfen yapıştırabilir misiniz?
benim yazımda bulabilirsin
Bence problem "kaynak" ın bir yerleşik olması ve kendi başına çalışması mantıklı değil.
bize [bu tartışmaya sohbette devam edin] (http://chat.stackexchange.com/rooms/6073/discussion-between-cupakob-and-alex-chamberlain)
Avio
2012-10-10 15:48:16 UTC
view on stackexchange narkive permalink

Komut dosyanızı cron 'a tedarik etmenin kesinlikle yapmak istediğiniz şey olduğundan ve daha da önemlisi gerekli olduğundan emin misiniz? Bunun neredeyse her zaman kötü bir fikir olduğunu düşünüyorum.

Dahası, cron 'u (ve diğer kullanıcılar ve / veya diğer mermiler tarafından başlatılabilecek diğer araçların yanı sıra) düzenlerken, adım adım ilerlemeye çalışın. -adım yaklaşımı. Örneğin, ortamınızı şu şekilde test edebilirsiniz: 

  42 * * * * bash -c "echo home --- $ HOME ---" >> / tmp / cron-temp .log 2>&142 * * * * bash -c "echo shell --- $ SHELL ---" >> /tmp/cron-temp.log 2>&1

veya hatta: 

  42 * * * * bash -c "dışa aktar" >> /tmp/cron-temp.log 2>&1

Böylece çevrenizin kanıtına sahip olabilirsiniz.

Sorunuzu yanıtlamak için, cron için kabuğunu değiştirmem. Ona basitçe bash 'ı çağırmasını ve ardından bash komut dosyalarınızı çağırmasını söylerdim.

$ SHELL, / etc / crontab dosyasında değiştirmeme rağmen hala 'sh' idi
Evet, aynı zamanda benim cron'umdaki varsayılan değer. Dediğim gibi, bunu değiştirmezdim. Betiğinizi "bash" ile "bash -c" yazıcınız "" ile çağırın ve her şey yoluna girecek (betiğinizi kaynaklamayın, muhtemelen ihtiyacınız yoktur!)
evet, bu işe yarayacak, ancak varsayılan kabuğun neden değiştirilmediğini bilmek istiyorum.
cupakob
2012-10-11 02:27:09 UTC
view on stackexchange narkive permalink

Yani .... sorunum için iki çözümüm var:

  1. Şu anda cronjob olarak adlandırdığım bash komutunun üzerine sarıcı komut dosyası. Buradaki sorun - her cronjob için bir paketleyiciye ihtiyacım var ve bu benim için en iyi çözüm değil.

  2. Bir ruby ​​betiğini cronjob olarak adlandırmaya çalıştım. Bu işe yaramıyor, bu yüzden 'rvm use 1.9.3'ü çağırmam gerektiğini ve bunun için önce' source ~ / .rvm / scripts / rvm 'çağrısı yapmam gerektiğini düşündüm. Ve işte benim hatam. Benim bash örneğimde Ruby'ye giden yolum var ama cron olarak değil. Bunu düzelttikten sonra, her şey yolunda gidiyor ve ruby ​​komut dosyalarımı da çalıştırabiliyorum.

Alex Chamberlain bana çok yardımcı oldu ve bana en önemli ipuçlarını verdi . Yardım için çok teşekkürler !!!



ⓘ
Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...