web-dev-qa-db-fra.com

@reboot de crontab ne fonctionne que pour root?

man 5 crontab est assez clair sur la façon d'utiliser crontab pour exécuter un script au démarrage:

   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.

J'ai donc heureusement ajouté une seule ligne à ma crontab (sous mon compte utilisateur, pas root):

@reboot     /home/me/myscript.sh

Mais pour une raison quelconque, myscript.sh ne fonctionnerait pas au redémarrage de la machine. (il fonctionne bien si je l'invoque à partir de la ligne de commande, donc ce n'est pas un problème de permissions)

Qu'est-ce que je rate?

Mise à jour pour répondre aux questions d'Anthon:

  1. Version Oracle-linux: 5.8 (uname: 2.6.32-300.39.2.el5uek # 1 SMP)
  2. Version Cron: vixie-cron-4.1-81.el5.x86_64
  3. Oui, /homeest une partition montée. On dirait que c'est le problème. Comment contourner cela?
  4. Actuellement, myscript.sh renvoie uniquement un message texte dans un fichier dans /home/me.
cronreboot
68
Withheld

Cela peut être un peu déroutant car il existe différentes implémentations de cron. Il y a également eu plusieurs bogues qui ont cassé cette fonctionnalité, et il y a aussi des cas d'utilisation où cela ne fonctionne tout simplement pas, en particulier si vous faites un arrêt/démarrage par rapport à un redémarrage.

Bugs

point de données # 1

Un de ces bogues dans Debian est couvert ici, intitulé: cron: les tâches @reboot ne sont pas exécutées . Cela semble avoir également fait son chemin dans Ubuntu, ce que je ne peux pas confirmer directement.

point de données # 2

La preuve du bogue dans Ubuntu semble être confirmée ici dans ce SO Q&A intitulé: @ reboot cronjob not executing .

extrait

commentaire # 1: .... 3) votre version de crond peut ne pas prendre en charge @reboot utilisez-vous le crond de vix? ... afficher les résultats de crontab -l -u user

commentaire # 2: ... Ce pourrait être une bonne idée de le configurer comme un script d'initialisation au lieu de compter sur une version spécifique de @reboot de cron.

commentaire # 3: ... @MarkRoberts a supprimé le redémarrage et modifié le 1 * * * *, en */1 * * * *, le problème est résolu! Où dois-je envoyer le représentant pts Mark? Je vous remercie!

La réponse acceptée dans cette Q&R comportait également ce commentaire:

Il me semble que Lubuntu ne prend pas en charge la syntaxe @Reboot Cron.

Preuve supplémentaire

point de données # 3

Comme preuve supplémentaire, il y avait ce fil que quelqu'un tentait la même chose et était frustré que cela ne fonctionne pas. Il est intitulé: Thread: Cron - @reboot jobs not working .

extrait

Re: Cron - Les emplois @reboot ne fonctionnent pas

Citation Envoyé par ceallred Voir le message Cela me tue ... J'ai essayé le script wrapper. L'exécution manuelle génère le fichier journal ... redémarrage et le travail ne s'exécute pas ou ne crée pas de fichier journal.

Syslog montre que CRON a exécuté le travail ... mais encore une fois, aucune sortie et le processus n'est pas en cours d'exécution. 15 juil 20:07:45 RavenWing cron [1026]: (CRON) INFO (exécution des travaux @reboot) 15 juil 20:07:45 RavenWing CRON [1053]: (ceallred) CMD (/ home/ceallred/Scripts/run_spideroak. sh> /home/ceallred/Scripts/SpiderOak.log 2> & 1 &)

Il semble que cron n'aime pas la commande @reboot .... D'autres idées?

D'accord ... Partiellement résolu. Je vais marquer celui-ci comme résolu et commencer un nouveau fil avec le nouveau problème .....

Je pense que la réponse était que mon répertoire personnel chiffré n'était pas monté lorsque CRON essayait d'exécuter le script (stocké dans/home/nom d'utilisateur/scripts). Déplacé vers/usr/scripts et le travail s'exécute comme prévu.

Alors maintenant, cela semble être un problème de spideroak. Le processus démarre, mais au moment où le processus de démarrage est terminé, il a disparu. J'imagine un crash pour une raison quelconque ... Nouveau fil de discussion à ce sujet.

Merci pour votre aide!

Une fois que cet utilisateur ci-dessus a découvert son problème, il a pu obtenir @reboot élaboration de l'entrée crontab d'un utilisateur.

Je ne sais pas vraiment quelle version de cron est utilisée sur Ubuntu, mais cela semblerait indiquer que l'utilisateur peut utiliser @reboot aussi, ou que le bogue a été corrigé à un moment donné dans les versions ultérieures de cron.

point de données # 4

J'ai testé sur CentOS 6 les éléments suivants et cela a fonctionné.

Exemple

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

J'ai ensuite redémarré le système.

$ Sudo reboot

Après le redémarrage.

$ cat reboot.txt 
hi

À emporter

  1. Cette fonctionnalité semble être prise en charge pour les entrées crontab système et utilisateur.
  2. Vous devez vous assurer qu'il est pris en charge/fonctionne dans votre distribution et/ou version particulière du paquet cron.

Pour en savoir plus sur le fonctionnement du mécanisme réel pour @reboot Je suis tombé sur ce billet de blog qui parle des entrailles. Il est intitulé: @ reboot - expliquant la magie cron simple .

Débogage crond

Vous pouvez augmenter la verbosité de crond en ajoutant ce qui suit à ce fichier de configuration sur les distributions basées sur RHEL/CentOS/Fedora.

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

Les niveaux valides sont 0, 1 ou 2. Pour rétablir ce fichier à son niveau de journalisation par défaut, supprimez simplement le "-L 2" lorsque vous avez terminé de déboguer la situation.

49
slm

J'ai découvert que sur ma machine Ubuntu, je n'ai pas encore accès aux services DNS, au moment de @reboot. Cela m'a empêché de monter des volumes distants. Cette solution ringarde, mais simple, a fonctionné:

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

(en root cron; dernières parties uniquement pour le débogage)

14
André

Je ne sais pas si vous avez déjà résolu cela, ou si l'une des solutions ci-dessus était la solution dont vous aviez besoin, mais une autre possibilité est:

si votre répertoire/home est crypté, il peut ne pas être disponible tant que vous ne vous êtes pas connecté, c'est-à-dire qu'il n'est pas disponible au redémarrage.

dans ce scénario, vous pouvez déplacer vos scripts vers un autre emplacement comme/srv ou/opt ou/usr/local/bin/etc.

3
fbas

J'ai aussi mac osx et j'ai eu le même problème où mon script n'était pas en cours d'exécution. mais quand j'ai corrigé mon script comme

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

cela a bien fonctionné pour moi. assurez-vous de rendre votre fichier Shell exécutable en exécutant la commande

chmod +x myscript.sh
3
Kidane

Prenez une nouvelle installation d'Ubuntu Gnome 13.10 (utilisateur par défaut dans mon cas: 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:

Et voyez qu'après avoir redémarré le fichier /var/tmp/xxx est là bien que il n'était pas là avant le redémarrage.

Cela a été fait avec cron version 3.0.

Vous devez vous assurer qu'aucun disque de services, etc. n'est utilisé qui pourrait ne pas être disponible au moment de l'exécution du script. Commencez avec quelque chose de simple comme ci-dessus et assurez-vous qu'il n'a pas de sortie de terminal, car le courrier électronique n'est probablement pas opérationnel.

Vous pourriez également avoir besoin d'un cron plus à jour (ou d'une mise à niveau d'Oracle-linux) si cela ne fonctionnait pas pour vous et que vous avez besoin de cette fonctionnalité.

1
Anthon

Tout d'abord, vous devez vous connecter en tant que root:

Sudo -i

Ouvrez ensuite crontab:

crontab -e

Après cela, ajoutez votre script à crontab en tant que root comme ci-dessous:

@reboot root/home/user1/Desktop/my_script

En conséquence, j'ai vu que mon script fonctionnait correctement.

Remarque: Si vous modifiez crontab avec votre utilisateur actuel, le redémarrage ne peut pas appeler votre script correctement.

0
Mustafa Kemal

Je dirais oui pour la question. J'ai juste eu des difficultés à exécuter cron au redémarrage (Debian 3.10.70) et j'ai réussi à résoudre avec:

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

Et un caractère de nouvelle ligne '\ n' à la fin

Voici le contenu du fichier:

/etc/cron.d/runOnReboot

Enfin, je pense qu'il vaut la peine de noter un résumé de man 5 crontab

... Le format d'une commande cron est très similaire à la norme V7, avec un certain nombre d'extensions à compatibilité ascendante. Chaque ligne comporte cinq champs d'heure et de date, suivis d'une commande, suivis d'un caractère de nouvelle ligne ('\ n'). La crontab système (/ etc/crontab) utilise le même format, sauf que le nom d'utilisateur de la commande est spécifié après les champs d'heure et de date et avant la commande. Les champs peuvent être séparés par des espaces ou des tabulations. La longueur maximale autorisée pour le champ de commande est de 998 caractères. ...

0
dmytro.poliarush