¿@reboot de crontab solo funciona para root?

man 5 crontab es bastante claro sobre cómo usar crontab para ejecutar un script en el arranque:

   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.

Así que felizmente agregué una sola línea a mi crontab (bajo mi cuenta de usuario, no root):

@reboot     /home/me/myscript.sh

Pero por alguna razón, myscript.sh no se ejecuta en el reinicio de la máquina. (funciona bien si lo invoco desde la línea de comandos, por lo que no es un problema de permisos)

¿Qué me estoy perdiendo?

Actualice para responder las preguntas de @ Anthon:

1. Versión de Oracle-Linux: 5.8 (uname: 2.6.32-300.39.2.el5uek # 1 SMP)
2. Versión de Cron: vixie-cron-4.1-81.el5.x86_64
3. Sí, /home es una partición montada. Parece que este es el problema. ¿Cómo soluciono esto?
4. Actualmente, myscript.shsolo envía un mensaje de texto a un archivo /home/me.

Este puede ser un tema un poco confuso porque hay diferentes implementaciones de cron. También hubo varios errores que rompieron esta característica, y también hay algunos casos de uso en los que simplemente no funcionará, específicamente si realiza un apagado / arranque frente a un reinicio.

Loco

punto de datos # 1

Aquí se cubre uno de estos errores en Debian, titulado: cron: los trabajos de @reboot no se ejecutan . Esto parece haber llegado también a Ubuntu, lo que no puedo confirmar directamente.

punto de datos # 2

La evidencia del error en Ubuntu parece confirmarse aquí en este SO Q&A titulado: @reboot cronjob no se está ejecutando .

extracto

comentario # 1: .... 3) su versión de crond puede no ser compatible con @reboot ¿está usando vix's crond? ... mostrar resultados de crontab -l -u usuario

comentario # 2: ... Podría ser una buena idea configurarlo como un script de inicio en lugar de confiar en una versión específica de cron's @reboot.

comentario # 3: ... @MarkRoberts eliminó el reinicio y modificó el 1 * * * *, a * / 1 * * * *, ¡el problema está resuelto! ¿Dónde envío a los representantes Mark? ¡Gracias!

La respuesta aceptada en ese Q&A también tenía este comentario:

Me parece que Lubuntu no admite la sintaxis de @Reboot Cron.

Evidencia adicional

punto de datos # 3

Como evidencia adicional había este hilo de que alguien estaba intentando lo mismo y se frustraba de que no funcionara. Se titula: Hilo: Cron: los trabajos de @reboot no funcionan .

extracto

Re: Cron - trabajos de reinicio no funcionan

Cita Originalmente publicado por ceallred View Post Esto me está matando ... Probé el script de envoltura. La ejecución manual genera el archivo de registro ... reiniciando y el trabajo no se ejecuta ni crea el archivo de registro.

Syslog muestra que CRON ejecutó el trabajo ... pero nuevamente, no hay salida y el proceso no se está ejecutando. 15 de julio 20:07:45 RavenWing cron [1026]: (CRON) INFORMACIÓN (Ejecutar @reboot jobs) 15 de julio 20:07:45 RavenWing CRON [1053]: (ceallred) CMD (/ home / ceallred / Scripts / run_spideroak. sh> /home/ceallred/Scripts/SpiderOak.log 2> & 1 &)

Parece que a cron no le gusta el comando @reboot ... ¿Alguna otra idea?

De acuerdo ... Parcialmente resuelto. Marcaré este como resuelto y comenzaré un nuevo hilo con el nuevo problema .....

Creo que la respuesta fue que mi directorio de inicio encriptado no estaba montado cuando CRON estaba tratando de ejecutar el script (almacenado en / home / username / scripts). Se movió a / usr / scripts y el trabajo se ejecuta como se esperaba.

Así que ahora parece ser un problema de spideroak. El proceso comienza, pero cuando termina el proceso de arranque, ya no está. Estoy adivinando un bloqueo por alguna razón ... Nuevo hilo para preguntar sobre eso.

¡Gracias por toda la ayuda!

Una vez que este usuario anterior descubrió su problema, pudo @reboottrabajar con la entrada crontab de un usuario.

No estoy completamente seguro de qué versión de cron se usa en Ubuntu, pero esto parece indicar que el usuario también puede usar @reboot, o que el error se corrigió en algún momento en versiones posteriores de cron.

punto de datos # 4

Probé en CentOS 6 lo siguiente y funcionó.

Ejemplo

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

Luego reinicié el sistema.

$ sudo reboot

Después del reinicio.

$ cat reboot.txt 
hi

Llevar lejos

1. Esta característica parece ser compatible con las entradas crontab del sistema y del usuario.
2. Debe asegurarse de que sea compatible / funcione en su distribución particular y / o versión del paquete cron.

Para obtener más información sobre cómo funciona el mecanismo real, @rebootme encontré con esta publicación de blog que analiza las entrañas. Se titula: @reboot: explica la magia cron simple .

Depuración de crond

Puede aumentar el nivel de detalle crondagregando lo siguiente a este archivo de configuración en distribuciones basadas en RHEL / CentOS / Fedora.

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

Los niveles válidos son 0, 1 o 2. Para revertir este archivo a su nivel de registro predeterminado, simplemente elimine "-L 2"cuando haya terminado de depurar la situación.

Descubrí que en mi máquina Ubuntu, todavía no tengo acceso a los servicios dns, en el momento del reinicio. Esto me impidió montar volúmenes remotos. Esta cursi, pero simple, solución funcionó:

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

(en root cron; últimas partes solo para depuración)

También tengo mac osx y tuve el mismo problema donde mi script no se estaba ejecutando. pero cuando arreglé mi script para gustar

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

Funcionó bien para mí. asegúrese de hacer que su archivo shell sea ejecutable ejecutando el comando

chmod +x myscript.sh

No sé si ya resolvió esto, o si alguna de las soluciones anteriores era la solución que necesitaba, pero otra posibilidad es:

si tiene su directorio / home encriptado, es posible que no esté disponible hasta que inicie sesión, es decir, no está disponible al reiniciar.

en este escenario, podría mover sus scripts a otra ubicación como / srv u / opt o / usr / local / bin / etc.

Realice una nueva instalación de Ubuntu Gnome 13.10 (usuario predeterminado en mi caso: 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: 

Y vea que después de reiniciar el archivo /var/tmp/xxxestá allí, aunque no estaba allí antes de reiniciar.

Esto se hizo con cron versión 3.0.

Debe asegurarse de que no se utilicen discos de servicios, etc. que puedan no estar disponibles en el momento en que se ejecuta el script. Comience con algo simple como lo anterior y asegúrese de que no tenga salida de terminal ya que el correo electrónico probablemente no esté funcionando.

Es posible que también necesite un cron más actualizado (o una actualización de oracle-linux) si esto no funcionó para usted y necesita esta función.

Yo diría que sí por la pregunta. Solo tuve dificultades para ejecutar cron al reiniciar (Debian 3.10.70) y logré resolverlo con:

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

Y un carácter de nueva línea '\ n' al final

Este es el contenido del archivo:

/etc/cron.d/runOnReboot

Finalmente, creo que vale la pena señalar un resumen de man 5 crontab

... El formato de un comando cron es muy similar al estándar V7, con varias extensiones compatibles con versiones anteriores. Cada línea tiene cinco campos de hora y fecha, seguidos de un comando, seguido de un carácter de nueva línea ('\ n'). El sistema crontab (/ etc / crontab) usa el mismo formato, excepto que el nombre de usuario para el comando se especifica después de los campos de hora y fecha y antes del comando. Los campos pueden estar separados por espacios o pestañas. La longitud máxima permitida para el campo de comando es de 998 caracteres. ...

En primer lugar, debe iniciar sesión como root:

sudo -i

Luego abra crontab:

crontab -e

Después de eso, agregue su script a crontab como root como a continuación:

@reboot root / home / user1 / Desktop / my_script

Como resultado, vi que mi guión funcionaba bien.

Nota: Si edita crontab con su usuario actual, el reinicio no puede llamar a su script correctamente.

prueba:

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

usuario @ ubuntu: ~ $ $ crontrab -e

@reboot /home/usuario/script.sh

guarda y reinicia tu pc