crontab's @reboot sadece root için çalışıyor mu?


64

man 5 crontab açılışta bir betiği çalıştırmak için crontab'ın nasıl kullanılacağı oldukça açıktır:

   These special time specification "nicknames" are supported, which replace the 5 initial time and date
   fields, and are prefixed by the `@` character:
   @reboot    :    Run once after reboot.

Böylece mutlu bir şekilde crontab'ıma tek bir satır ekledim (kullanıcı hesabımın altında, root değil):

@reboot     /home/me/myscript.sh

Ancak bazı nedenlerden dolayı, myscript.sh, makine yeniden başlatıldığında çalışmayacaktır. (komut satırından çağırırsam iyi çalışır, bu nedenle izin sorunu değil)

Neyi kaçırıyorum?


Anthon'un sorularını yanıtlamak için güncelleme:

  1. Oracle-linux sürümü: 5.8 (uname: 2.6.32-300.39.2.el5uek # 1 SMP)
  2. Cron versiyonu: vixie-cron-4.1-81.el5.x86_64
  3. Evet, /home olan bir monte bölümü. Sorun bu gibi görünüyor. Bunu nasıl geçici olarak çözebilirim?
  4. Şu anda, myscript.shyalnızca içindeki bir dosyaya metin mesajı eko /home/me.

2
kullanıcı crontab'ınız @reboot seçeneğini desteklemiyor, etrafta dolaşmaya başladığınızda birkaç crontab düzeni var.
X Tian

@ XTian Teşekkürler. Bir betiği root dışında bir kullanıcı olarak yeniden başlatırken çalıştırmanın önerilen yolu nedir?
Withheld

2
Eksik olduğun net değil ama eksik olduğumuz detaylar. Hangi Linux-Linux sürümünü kullanıyorsunuz? Hangi cron versiyonuna sahipsiniz? Mı /homebir monte bölümü? İçeriğiniz nedir /home/me/myscript.sh?
Anthon

1
Oracle'ın Lin kullanıyorsanız. ver. 5 vixie-cron + ile ilgili konularda bu değişmezlik var @reboot. oss.oracle.com/pipermail/el-errata/2012-Mart/002655.html
slm

1
@Daniel - myscript.shçalıştırılabilir mi? chmod +x myscript.sh.
slm

Yanıtlar:


47

Bu biraz kafa karıştırıcı bir konu olabilir, çünkü farklı cron uygulamaları var. Ayrıca, bu özelliği bozan birkaç hata vardı ve özellikle yeniden başlatma gibi bir kapatma / önyükleme yaparsanız basitçe işe yaramayacağı bazı kullanım durumları da var.

Hatalar

veri noktası # 1

Debian'da böylesi bir hata burada ele alınmıştır, başlıklı: cron: @ reboot jobs çalıştırılmaz . Bu, doğrudan doğrulayamadığım Ubuntu'ya da girmiş görünüyor.

veri noktası # 2

Ubuntu'daki hatanın kanıtı burada bu SO Soru ve Cevap bölümünde doğrulanmış gibi görünüyor: @reboot cronjob yürütülmüyor .

alıntı

comment # 1: .... 3) Crond versiyonunuz @reboot'u desteklemeyebilir. vix'in crond'unu kullanıyor musunuz? ... crontab -l -u user sonuçlarını göster

comment # 2: ... cron'un @reboot dosyasının belirli bir sürümüne güvenmek yerine init betiği olarak ayarlamak iyi bir fikir olabilir.

comment # 3: ... @MarkRoberts yeniden başlatmayı kaldırdı ve 1 * * * *, * / 1 * * * * olarak değiştirildi, sorun çözüldü! Mark'ları nereye gönderirim? Teşekkür ederim!

Soru-Cevap’da kabul edilen cevap şu yorumu da yaptı:

Görünüşe göre Lubuntu @Reboot Cron sözdizimini desteklemiyor.

Ek kanıt

veri noktası # 3

Ek kanıt olarak, bir başkasının aynı şeyi denediğini ve işe yaramadığını hayal kırıklığına uğrattığını gösteren bir konu vardı. Başlıklı: Konu: Cron - @reboot işleri çalışmıyor .

alıntı

Re: Cron - @reboot işleri çalışmıyor

Alıntı Başlangıçta tarafından gönderildi ceallred Mesaj gösterimi Bu beni öldürüyor ... sarıcı betiği denedim. El ile çalıştırmak günlük dosyasını oluşturur ... yeniden başlatılıyor ve iş çalışmıyor veya günlük dosyası oluşturmuyor.

Syslog, CRON'un işi yürüttüğünü gösteriyor ... ama yine de çıktı yok ve işlem çalışmıyor. 15 Temmuz 20:07:45 RavenWing cron [1026]: (CRON) INFO (Çalışan @reboot işleri) Jul 15 20:07:45 RavenWing CRON [1053]: (durdu) CMD (/ home / ceallred / Scripts / run_spideroak). sh> /home/ceallred/Scripts/SpiderOak.log 2> & 1 &)

Bu cron @ reboot komutunu sevmiyor gibi görünüyor .... Başka bir fikrin var mı?

Tamam ... Kısmen çözüldü. Bunu çözülmüş olarak işaretleyeceğim ve yeni sayı ile yeni bir konu başlatacağım .....

Sanırım cevabı, CRON betiğini çalıştırmaya çalışırken (/ home / username / scripts içinde) şifreli bir giriş dizini kurulmadı. / Usr / script'e taşındı ve iş beklendiği gibi çalışıyor.

Yani şimdi bir spideroak sorunu gibi görünüyor. İşlem başlar, ancak önyükleme işlemi bittiğinde, işlem bitmiştir. Nedense bir çökme tahmin ediyorum .... Bu konuda sorulacak yeni konu.

Tüm yardımların için teşekkürler!

Yukarıdaki kullanıcı sorununu anladıktan sonra @reboot, bir kullanıcının crontab girişinde çalışabildi .

Ubuntu'da hangi cron sürümünün kullanıldığından tam olarak emin değilim, ancak bu, kullanıcının da kullanabileceğini @rebootveya hatanın cron'un sonraki sürümlerinde bir noktada çözüldüğünü gösteriyor gibi görünüyor.

veri noktası # 4

Aşağıdakileri CentOS 6'da test ettim ve işe yaradı.

Örnek

$ crontab -l
@reboot echo "hi" > /home/sam/reboot.txt 2>&1

Daha sonra sistemi yeniden başlattım.

$ sudo reboot

Yeniden başlattıktan sonra.

$ cat reboot.txt 
hi

Uzaklaş

  1. Bu özellik hem sistem hem de kullanıcı crontab girişleri için desteklenmiş görünmektedir.
  2. Özel dağıtımınızda ve / veya cron paketinin sürümünde desteklendiğinden / çalıştığından emin olmalısınız.

Asıl mekanizmanın nasıl çalıştığı hakkında daha fazla bilgi @rebootiçin doğuştan gelenleri tartışan bu blog yazısı ile karşılaştım. Başlığı : @reboot - basit cron sihrini açıklamak .

Hata ayıklama crond

crondRHEL / CentOS / Fedora tabanlı dağıtımlarda bu yapılandırma dosyasına aşağıdakileri ekleyerek ayrıntılarını artırabilirsiniz .

$ more crond 
# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS="-L 2"

Geçerli seviyeler 0, 1 veya 2'dir. Bu dosyayı varsayılan ayar seviyesine geri döndürmek "-L 2"için durumun hata ayıklamasını bitirdiğinizde basitçe kaldırın .


Dün bir yorum yaptım, cevabına baktım ve iyi bir gece uykusundan sonra kendime cevap vermeye karar verdim. Bir VM kurun, yeniden denedi, yeniden cevapladı, cevabımı yollamak istedim ve ancak daha sonra cevabınızı 'yeniden' değerlendirdiğini 'gördüm :-(
Anthon

@Anthon - üzgünüm, dün çabucak cevapladım ve araştırmaya devam ettim ve çok çelişkili detaylar buldum. Debian'daki ve Ubuntu SO'daki hatayı bulduğumda oyundakilerin bir kısmını anladım. CentOS üzerinde çalıştığını gördüm ve bir araya getirip @rebootbelirli pilavlarda tamam olduğunu ve görünüşe göre diğerlerinde kırıldığını / kırıldığını gördüm . Dolayısıyla karışıklık.
slm

Bunun dışında, OP çok az ayrıntı sağlar, betiğinizde henüz çalışmayan (önyükleme zamanında) çalışmayan bir şeyi kolayca çalıştırabilen veya henüz monte edilmemiş bir diskte bulundurarak kolayca kullanabilirsiniz. OP'nin yorum yaptığı cevabım, bir de üçüncü tarafça onaylandı. Bu kara kuğu sorunu ...
Anthon

@Anthon - evet, veri noktalarımdan biri tam olarak buydu. @rebootbir an önce çalıştığım şifreli bir sürücüye erişmeye çalıştığını anladıktan sonra çalıştı.
slm

3
Bir gecikme ekleyerek Ubuntu hata kolayca çözüldüğünü işaret etmek isteyebilirsiniz: @reboot sleep 60; <your command>. Konuyu alıntılamak gerekirse, "tahminim,
cron'un @reboot

12

Ubuntu makinemde, @reboot zamanında henüz dns servislerine erişimim olmadığını öğrendim. Bu uzak hacimleri monte etmemi engelledi. Bu corny, henüz basit, çözüm çalıştı:

@reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log

(root cron'da; sadece hata ayıklama için son bölümler)


Bu aslında root olmayan kullanıcılar için ubuntu 16.04 üzerinde çalışan tek şey!
Aleksandar Pavić

Debian 8 jessie (gnome 3) üzerinde çalışmıyor. :(
Tadej

VMWare paylaşılan klasörlerini ayrı bir yere monte etmekle uğraşırken bu benim için çalıştı.
jgshawkey

3

Benim de mac osx'um var ve senaryomun çalışmadığı yerlerde de aynı sorun vardı. ama senaryomu düzeltirken

@reboot   cd /home/me/  && sh myscript.sh

Benim için iyi çalıştı. Komutu çalıştırarak kabuk dosyanızı çalıştırılabilir hale getirdiğinizden emin olun.

chmod +x myscript.sh

2

Bunu daha önce çözdünüz mü, yoksa yukarıdakilerden herhangi biri ihtiyaç duyduğunuz çözüm ise bilmiyorum, ancak başka bir olasılık:

/ home dizininiz şifrelenmişse, giriş yapana kadar kullanılamayabilir, yani yeniden başlatılmada kullanılamaz.

Bu senaryoda, komut dosyalarınızı / srv veya / opt veya / usr / local / bin / etc gibi başka bir konuma taşıyabilirsiniz.


1

Ubuntu Gnome 13.10'un yeni kurulumunu yapın (benim durumumda varsayılan kullanıcı: avanderneut).

avanderneut@uggo:~$ crontab -l
no crontab for avanderneut
avanderneut@uggo:~$ crontab -e
no crontab for avanderneut - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/vim.tiny

Choose 1-3 [2]: 3
crontab: installing new crontab
avanderneut@uggo:~$ crontab -l | tail -2
# m h  dom mon dow   command
@reboot /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ more !$
more /home/avanderneut/bin/on_reboot
#! /bin/bash
echo "Reboot script" > /var/tmp/xxx
avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
xxx
avanderneut@uggo:~$ rm /var/tmp/xxx
avanderneut@uggo:~$ sudo reboot
[sudo] password for avanderneut: 

Ve yeniden başlatmadan sonra dosyayı yeniden başlatmadan önce /var/tmp/xxxorada olmamasına rağmen orada olduğunu görün.

Bu cron sürüm 3.0 ile yapıldı.

Komut dosyası çalışırken kullanılamayacak hizmet disklerinin vb. Kullanılmadığından emin olmalısınız. Yukarıdaki gibi basit bir şeyle başlayın ve e-posta muhtemelen çalışmadığı için terminal çıkışı olmadığından emin olun.

Bu sizin için işe yaramadıysa ve bu özelliğe ihtiyacınız varsa, daha güncel bir cron (ya da oracle-linux'tan yükseltme) gerekebilir.


Sorularınızı yanıtlamak için OP’mi güncelledim Şüphenizin en baştan doğru olduğu ortaya çıktı: Yeniden başlatmada çalıştırılacak olan komut dosyası, monte edilebilir bir /dev/mapper/VolGroup00-LogVol01bölümde duruyor .
Withheld

@Daniel Haber verdiğin için teşekkürler, suçluyu bulduğuna sevindim. Bölmeler monte edilinceye kadar cronun başlangıcını geciktirip geciktiremeyeceğinizden emin değilim, bu başlangıç ​​işlemlerinin bazıları paralel olarak yapılır ve bağımlılıkları değiştirmeniz gerekecektir. Bu ve olası bir mola ile uğraşmak istemem cron. Bir kullanıcı olarak başlangıçta bir şey çalıştırmak için IMHO crontab & @reboot'tan farklı bir rota izlemelisiniz.
Anthon

0

Soru için evet derdim. Yeniden başlatırken cron çalıştırmakta zorluk çekiyordum (Debian 3.10.70) ve aşağıdakileri çözmeyi başardı:

@reboot root /usr/bin/python3 /path/to/script

Ve sonunda '\ n' yeni satır karakteri

Bu dosyanın içeriği:

/etc/cron.d/runOnReboot

Sonunda, benden bir soyut kaydetmeye değer olduğunu düşünüyorum man 5 crontab

... Bir cron komutunun formatı, pek çok yukarı doğru uyumlu uzantıya sahip olan V7 standardıdır. Her satırın beş saat ve tarih alanı vardır, bunu bir komut izler, ardından bir yeni satır karakteri ('\ n') izler. Sistem crontab (/ etc / crontab) komutun kullanıcı adının saat ve tarih alanlarından ve komuttan önce belirtilmesi dışında aynı formatı kullanır. Alanlar boşluklarla veya sekmelerle ayrılabilir. Komut alanı için izin verilen maksimum uzunluk 998 karakterdir. ...


0

Öncelikle, root olarak giriş yapmalısınız:

sudo -i

Ardından crontab'ı açın:

crontab -e

Bundan sonra, betiğinizi crontab'a aşağıdaki gibi root olarak ekleyin:

@reboot root / home / kullanıcı1 / Masaüstü / my_script

Sonuç olarak senaryomun doğru çalıştığını gördüm.

Not: Geçerli kullanıcıyla crontab'ı düzenlerseniz, yeniden başlatma komut dosyasını düzgün şekilde arayamaz.


-1

prueba:

usuario @ ubuntu: ~ $ dokunmadan script.sh usuario @ ubuntu: ~ $ chmod + x

usuario @ ubuntu: ~ $ $ crontrab -e

@reboot /home/usuario/script.sh

PC'nizi kaydedin ve yeniden başlatın

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.