crontab @reboot działa tylko dla roota?

man 5 crontab jest całkiem jasne, jak używać crontab do uruchamiania skryptu podczas uruchamiania:

   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.

Więc z radością dodałem jedną linię do mojego crontab (pod moim kontem użytkownika, a nie rootem):

@reboot     /home/me/myscript.sh

Ale z jakiegoś powodu myscript.sh nie uruchomi się przy ponownym uruchomieniu komputera. (działa poprawnie, jeśli wywołam go z wiersza poleceń, więc nie jest to problem z uprawnieniami)

czego mi brakuje?

Zaktualizuj, aby odpowiedzieć na pytania @ Anthon:

1. Wersja Oracle-Linux: 5.8 (uname: 2.6.32-300.39.2.el5uek # 1 SMP)
2. Wersja Cron: vixie-cron-4.1-81.el5.x86_64
3. Tak, /home jest zamontowaną partycją. Wygląda na to, że to jest problem. Jak to obejść?
4. Obecnie myscript.shtylko echo wiadomości tekstowej do pliku w /home/me.

Może to być nieco mylące, ponieważ istnieją różne implementacje crona. Było też kilka błędów, które zepsuły tę funkcję, i są też przypadki użycia, w których po prostu nie zadziała, szczególnie jeśli wykonasz zamknięcie / uruchomienie zamiast restartu.

Robaki

punkt danych 1

Omówiono tutaj jeden z takich błędów w Debianie, zatytułowany: cron: zadania @reboot nie są uruchamiane . Wydaje się, że dotarło to również do Ubuntu, czego nie mogę bezpośrednio potwierdzić.

punkt danych 2

Dowód błędu w Ubuntu wydaje się być potwierdzony tutaj w tym SO Q&A zatytułowanym: @reboot cronjob nie wykonuje się .

fragment

komentarz nr 1: .... 3) Twoja wersja crond może nie obsługiwać @reboot czy używasz crond vix? ... pokaż wyniki użytkownika crontab -l -u

komentarz # 2: ... Dobrym pomysłem może być skonfigurowanie go jako skryptu inicjującego zamiast polegania na konkretnej wersji @reboot crona.

komentarz # 3: ... @ MarkRoberts usunął restart i zmodyfikował 1 * * * *, do * / 1 * * * *, problem został rozwiązany! Gdzie mam wysłać przedstawiciela Marka? Dziękuję Ci!

Przyjęta odpowiedź w tym pytaniu i odpowiedzi zawierała również ten komentarz:

Wydaje mi się, że Lubuntu nie obsługuje składni @Reboot Cron.

Dodatkowe dowody

punkt danych nr 3

Dodatkowym dowodem był wątek, że ktoś próbował zrobić to samo i denerwował się, że to nie zadziałało. Nosi tytuł: Wątek: Cron - zadania @reboot nie działają .

fragment

Re: Cron - zadania @reboot nie działają

Cytat Zamieszczone przez ceallred View Post To mnie zabija ... Próbowałem skryptu opakowania. Uruchomienie ręczne generuje plik dziennika ... restartuje się, a zadanie nie uruchamia się ani nie tworzy pliku dziennika.

Syslog pokazuje, że CRON uruchomił zadanie ... ale ponownie, brak danych wyjściowych i proces nie działa. 15 lipca 20:07:45 RavenWing cron [1026]: (CRON) INFO (Uruchamianie zadań @reboot) 15 lipca 20:07:45 RavenWing CRON [1053]: (przywrócony) CMD (/ home / ceallred / Scripts / run_spideroak. sh> /home/ceallred/Scripts/SpiderOak.log 2> i 1 i)

Wygląda na to, że cron nie lubi polecenia @reboot ... Jakieś inne pomysły?

Ok ... Częściowo rozwiązany. Oznaczę ten jako rozwiązany i rozpocznę nowy wątek z nowym problemem .....

Myślę, że odpowiedzią było, że mój zaszyfrowany katalog domowy nie został podłączony, gdy CRON próbował uruchomić skrypt (przechowywany w / home / nazwa użytkownika / skrypty). Przeniesiono do / usr / scripts i zadanie działa zgodnie z oczekiwaniami.

Teraz wydaje się, że jest to kwestia pająka pająka. Proces rozpoczyna się, ale do czasu zakończenia procesu rozruchu nie ma go. Z jakiegoś powodu zgaduję awarię ... Nowy wątek, aby o to zapytać.

Dzięki za wszelką pomoc!

Gdy ten powyżej użytkownik zorientował się, jaki jest jego problem, był w stanie zacząć @rebootpracę od wpisu crontab użytkownika.

Nie jestem do końca pewien, jakiej wersji crona używa się na Ubuntu, ale wydaje się to wskazywać, że użytkownik może @rebootrównież użyć lub że błąd został naprawiony w pewnym momencie w kolejnych wersjach crona.

punkt danych # 4

Testowałem na CentOS 6 następujące i działało.

Przykład

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

Następnie ponownie uruchomiłem system.

$ sudo reboot

Po ponownym uruchomieniu.

$ cat reboot.txt 
hi

Wynos

1. Wydaje się, że ta funkcja jest obsługiwana zarówno dla wpisów crontab systemu, jak i użytkownika.
2. Musisz upewnić się, że jest obsługiwany / działa w twojej konkretnej dystrybucji i / lub wersji pakietu cron.

Aby dowiedzieć się więcej o tym, jak działa ten mechanizm, @rebootnatknąłem się na tego posta na blogu, który omawia wnętrze. Nosi tytuł: @reboot - wyjaśnianie prostej magii cron .

Debugowanie crond

Można zwiększyć poziom szczegółowości crond, dodając następujące elementy do tego pliku konfiguracyjnego w dystrybucjach opartych na RHEL / CentOS / Fedora.

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

Prawidłowe poziomy to 0, 1 lub 2. Aby przywrócić ten plik do domyślnego poziomu rejestrowania, po prostu usuń po zakończeniu "-L 2"debugowania sytuację.

Dowiedziałem się, że na moim komputerze Ubuntu nie mam jeszcze dostępu do usług dns w czasie @reboot. To uniemożliwiło mi montaż zdalnych woluminów. To banalne, ale proste rozwiązanie zadziałało:

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

(w root cron; ostatnie części tylko do debugowania)

Mam również Mac OSX i miałem ten sam problem, w którym mój skrypt nie był uruchomiony. ale kiedy poprawiłem skrypt

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

działało dla mnie dobrze. upewnij się, że plik powłoki jest wykonywalny, uruchamiając polecenie

chmod +x myscript.sh

Nie wiem, czy już to rozwiązałeś, czy też jedno z powyższych rozwiązań było potrzebne, ale inna możliwość to:

jeśli masz zaszyfrowany katalog / home, może on nie być dostępny, dopóki się nie zalogujesz, tzn. nie będzie dostępny przy ponownym uruchomieniu.

w tym scenariuszu możesz przenieść skrypty do innej lokalizacji, takiej jak / srv lub / opt lub / usr / local / bin / itp.

Weź świeżą instalację Ubuntu Gnome 13.10 (domyślny użytkownik w moim przypadku: 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: 

I zobacz, że po ponownym uruchomieniu plik /var/tmp/xxxistnieje, chociaż nie było go przed ponownym uruchomieniem.

Dokonano tego z wersją 3.0 crona.

Musisz upewnić się, że nie są używane dyski z usługami itp., Które mogą być niedostępne w momencie uruchomienia skryptu. Zacznij od czegoś tak prostego jak powyższy i upewnij się, że nie ma on danych wyjściowych na terminalu, ponieważ prawdopodobnie e-mail nie działa.

Możesz także potrzebować bardziej aktualnego crona (lub aktualizacji z oracle-linux), jeśli to nie zadziałało i potrzebujesz tej funkcji.

W przypadku pytania powiedziałbym „tak”. Miałem tylko problemy z uruchomieniem crona przy ponownym uruchomieniu (Debian 3.10.70) i ​​udało mi się rozwiązać za pomocą:

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

I na końcu znak nowej linii „\ n”

To jest zawartość pliku:

/etc/cron.d/runOnReboot

Wreszcie uważam, że warto zauważyć streszczenie man 5 crontab

... Format polecenia cron jest w dużej mierze standardem V7, z wieloma rozszerzeniami kompatybilnymi w górę. Każda linia ma pięć pól daty i godziny, po których następuje polecenie, a po nim znak nowej linii („\ n”). Systemowy plik crontab (/ etc / crontab) używa tego samego formatu, z tym wyjątkiem, że nazwa użytkownika dla polecenia jest podana po polach godziny i daty oraz przed poleceniem. Pola mogą być oddzielone spacjami lub tabulatorami. Maksymalna dozwolona długość pola polecenia wynosi 998 znaków. ...

prueba:

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

usuario @ ubuntu: ~ $ $ crontrab -e

@reboot /home/usuario/script.sh

zapisz i uruchom ponownie komputer