He utilizado estas 2 referencias para insertar una nueva entrada de crontab.
Creé un nuevo archivo bash y lo moví a /usr/bin. Ese archivo sh tiene permisos de ejecución para el usuario root y el grupo de administración. El archivo bash simplemente repite una línea en un archivo de registro y luego llama a un programa java. Probé el archivo sh como root, manualmente. Funciona bien. Mi entrada de crontab se ve así...
@hourly /usr/bin/foo.blah.sh
Se supone que debe funcionar cada hora. La declaración de eco no se imprime en el archivo de registro, por lo que no creo que crond la llame en absoluto. Además, cuando superviso visualmente los procesos en "arriba", el trabajo nunca aparece. He ejecutado "estado crond del servicio" para verificar que el demonio cron se esté ejecutando. La documentación dice que no es necesario reiniciar el demonio. ¿Qué más podría estar haciendo mal?
Respuesta1
En realidad, no dice dónde está la entrada crontab, pero según el comentario que crontab -lgenera no crontab for root, me atrevería a suponer que ha agregado un archivo en uno de los directorios /etc/cron.*, que contiene archivos correspondientes a varios cron. trabajos. Esta respuesta supone que ese es el caso.
Esos archivos tienen un formato que es ligeramente diferente del crontab específico del usuario mediante el cual edita crontab -e. Específicamente,Incluyen un campo de nombre de usuario.justo antes del comando, que no está incluido en el crontab específico del usuario (que al menos en mi sistema se almacena en /var/spool/cron/crontabs, pero no abuse de esa información; la ubicación exacta es un detalle de implementación del demonio cron que está ejecutando y debe usar las interfaces documentadas para administrar esos archivos).
Como resultado,deberías cambiar
@hourly /usr/bin/foo.blah.sh
a
@hourly user /usr/bin/foo.blah.sh
¿Dónde userestá el nombre de la cuenta de usuario para ejecutar el script? Entonces debería funcionar bien.
Realmente te animo a que no ejecutes trabajos cron a rootmenos que sea necesario; Hacer cualquier cosa como superusuario siempre es un riesgo para la seguridad. Si es posible, asigne al script su propia cuenta con acceso restringido. (Este es el principio de privilegio mínimo; es decir, lo mínimo que se requiere para que haga su trabajo). Como regla general, debe colocararchivos locales del sistema en /usr/localpara evitar conflictos con el administrador de paquetes del sistema; Además, para evitar confusiones, no coloque elementos en ningún directorio bin que necesite privilegios de root para funcionar; utilice sbin en su lugar.
Respuesta2
En el pasado, cuando agregaba scripts a cron, siempre iniciaba la línea con sh, así:
@hourly sh /usr/bin/foo.blah.sh