@reboot de crontab ne fonctionne que pour root?

65

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.

Alors j’ai 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. (ça marche bien si je l'invoque depuis la ligne de commande, donc ce n'est pas un problème d'autorisations)

Qu'est-ce que je rate?


Mise à jour pour répondre aux questions de @ 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, /home est une partition montée. On dirait que c'est le problème. Comment puis-je contourner ce problème?
  4. À l’heure actuelle, myscript.shseul un message texte est envoyé à un fichier dans /home/me.
Retenu
la source
2
votre utilisateur crontab ne supporte pas l'option @reboot, il y a quelques dispositions de crontab, une fois que vous commencez à fouiller.
X Tian
@XTian Merci. Quelle est la méthode recommandée pour exécuter un script au redémarrage en tant qu’utilisateur autre que root?
Retenu
2
Ce qui vous manque n’est pas clair, mais ce qui nous manque, ce sont des détails. Quelle version d'Oracle-linux utilisez-vous? Quelle version de cron avez-vous? Est-ce /homeune partition montée? Quel est le contenu de votre /home/me/myscript.sh?
Anthon
1
Si vous utilisez Oracle Lin. ver. 5 il y a ce changelog sur les problèmes avec vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html
slm
1
@ Daniel - est myscript.shexécutable? chmod +x myscript.sh.
slm

Réponses:

48

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

Bogues

point de donnée n ° 1

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

point de donnée n ° 2

La preuve du bogue dans Ubuntu semblerait être confirmée ici dans ce SO Q & A intitulé: @reboot cronjob ne s'exécutant pas .

extrait

comment # 1: .... 3) votre version de crond peut ne pas supporter @reboot utilisez-vous crond de vix? ... afficher les résultats de l'utilisateur crontab -l -u

commentaire n ° 2: ... Ce serait peut-être une bonne idée de le configurer en tant que script d'initialisation au lieu de s'appuyer sur une version spécifique de @reboot de cron.

commentaire n ° 3: ... @MarkRoberts a supprimé le redémarrage et modifié le 1 * * * *, en * / 1 * * * *, le problème est résolu! Où est-ce que j'envoie les reps Mark? Je vous remercie!

La réponse acceptée dans ce Q & A avait également ce commentaire:

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

Preuves supplémentaires

point de donnée n ° 3

Comme preuve supplémentaire, il y avait ce fil conducteur que quelqu'un tentait exactement la même chose et devenait frustré que cela ne fonctionne pas. Il s'intitule: Thread: Cron - Les travaux @reboot ne fonctionnent pas .

extrait

Re: Cron - Les travaux @reboot ne fonctionnent pas

Citation Envoyé par ceallred Voir le message C'est en train de me tuer ... J'ai essayé le script d'emballage. L'exécution manuelle génère le fichier journal ... en cours de redémarrage et le travail ne s'exécute ni ne crée de fichier journal.

Syslog montre que CRON a exécuté le travail ... mais encore une fois, aucune sortie et le processus ne sont pas en cours d'exécution. 15 juillet 20:07:45 RavenWing cron [1026]: (CRON) INFO (Exécution de travaux @reboot) 15 juillet 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 ... Avez-vous d'autres idées?

Ok ... Partiellement résolu. Je marquerai celui-ci comme résolu et je commencerai un nouveau fil avec le nouveau numéro .....

Je pense que la réponse était que mon répertoire personnel crypté 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 commence, mais à la fin du processus de démarrage, il est terminé. Je devine un crash pour une raison quelconque ... Nouveau sujet à poser à ce sujet.

Merci pour votre aide!

Une fois que cet utilisateur ci-dessus a découvert son problème, il était capable de @reboottravailler avec l'entrée crontab d'un utilisateur.

Je ne suis pas tout à fait sûr de la version de cron utilisée sur Ubuntu, mais cela semblerait indiquer que l'utilisateur peut @rebootégalement l' utiliser , ou que le bogue a été corrigé à un moment donné dans les versions ultérieures de cron.

point de donnée n ° 4

J'ai testé sur CentOS 6 ce qui suit 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 de la crontab du système et de l'utilisateur.
  2. Vous devez vous assurer qu'il est pris en charge / fonctionne dans votre distribution et / ou version du paquetage cron.

Pour en savoir plus sur le fonctionnement du mécanisme actuel, @rebootje suis tombé sur ce billet de blog qui traite des entrailles. Il s'intitule: @reboot - explique la simple magie cron .

Debugging Crond

Vous pouvez augmenter la verbosité de cronden ajoutant les éléments suivants à 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 le niveau de consignation par défaut de ce fichier, supprimez simplement le "-L 2"moment où vous avez terminé de déboguer la situation.

slm
la source
J'ai eu un commentaire hier, j'ai regardé ta réponse et décidé de me répondre après une bonne nuit de sommeil. Mettre en place une machine virtuelle, retenté @reboot, voulait publier ma réponse et alors seulement vous voyiez "reformuler" votre réponse :-(
Anthon
@Anthon - désolé, j'ai rapidement répondu à cette question hier, puis j'ai poursuivi mes recherches et trouvé des détails très contradictoires. Quand j’ai trouvé le bogue sur Debian à ce sujet et sur SO Ubuntu, j’ai réalisé une partie de ce qui se passait. J'ai vu que cela fonctionnait sur CentOS et je l'ai assemblé, ce qui @rebootest acceptable dans certains cas et apparemment défectueux dans d'autres. D'où la confusion.
slm
En dehors de cela, l'OP fournit peu de détails, vous pouvez facilement utiliser quelque chose qui ne fonctionne pas encore (au moment du démarrage) dans votre script et qui le fait échouer, ou le faire résider sur un disque non encore monté. Ma réponse, commentée par le PO, a également été confirmée par une 3ème partie. C'est le problème du cygne noir ...
Anthon
@ Anthony - oui, un de mes points de données était exactement cela. @reboota fonctionné une fois que vous avez réalisé qu’il essayait d’accéder à un lecteur chiffré, qui n’avait pas encore été monté.
slm
3
Vous pouvez remarquer que le bogue dans Ubuntu est facilement résolu en ajoutant un retard: @reboot sleep 60; <your command>. Pour citer le fil, "je suppose que la directive @reboot de cron est trop avancée dans le processus de démarrage"
pzkpfw le
12

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

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

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

André
la source
C’est la seule chose qui fonctionne réellement sur Ubuntu 16.04 pour les utilisateurs non root!
Aleksandar Pavić
Ne fonctionne pas sur Debian 8 Jessie (gnome 3). :(
Tadej
Cela a fonctionné pour moi lors du montage de dossiers partagés VMWare sur un emplacement distinct.
jgshawkey
3

J'ai aussi mac osx et j'ai eu le même problème où mon script ne fonctionnait pas. mais quand j'ai corrigé mon script pour aimer

@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
Kidane
la source
2

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

Si votre répertoire / home est crypté, il peut ne pas être disponible tant que vous n'ê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, tel que / srv ou / opt ou / usr / local / bin / etc.

fbas
la source
1

Prenez une nouvelle installation de 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 le redémarrage, le fichier /var/tmp/xxxest là bien qu'il ne soit pas là avant le redémarrage.

Cela a été fait avec la version 3.0 de cron.

Vous devez vous assurer qu'aucun disque de service, etc., n'est utilisé et 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 récent (ou d’une mise à jour d’oracle-linux) si cela ne fonctionnait pas pour vous et si vous aviez besoin de cette fonctionnalité.

Anthon
la source
J'ai mis à jour mon OP pour répondre à vos questions. Il se trouve que vous aviez le doute depuis le début: Le script à exécuter au redémarrage réside sur une /dev/mapper/VolGroup00-LogVol01partition pouvant être montée.
Retenu
@ Daniel Merci de me le faire savoir, je suis heureux que vous ayez trouvé le coupable. Je ne sais pas si vous pouvez retarder le démarrage de cron jusqu'à ce que les partitions soient montées, une partie de ce démarrage est effectuée en parallèle et vous devrez modifier les dépendances. Je ne voudrais pas jouer avec cela et une pause possible cron. IMHO devrait suivre un chemin différent de celui de crontab & @reboot pour exécuter quelque chose une fois au démarrage en tant qu'utilisateur.
Anthon
0

Je dirais oui pour la question. Je viens de rencontrer des difficultés pour 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

Ceci est le contenu du fichier:

/etc/cron.d/runOnReboot

Enfin, je pense qu’il est intéressant de noter un résumé de man 5 crontab

... Le format d'une commande cron correspond en grande partie au standard V7, avec un certain nombre d'extensions compatibles vers le haut. 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 du 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 heure et 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. ...

dmytro.poliarush
la source
0

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

sudo -i

Puis ouvrez crontab:

crontab -e

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

@ root 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.

Mustafa Kemal
la source
-1

prueba:

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

usuario @ ubuntu: ~ $ $ crontrab -e

@reboot /home/usuario/script.sh

enregistrer et redémarrer votre pc

gnuman
la source