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 @reboot
travailler 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
- Cette fonctionnalité semble être prise en charge pour les entrées de la crontab du système et de l'utilisateur.
- 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, @reboot
je 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 crond
en 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.