Solución 1:
Puede ser útil tener en cuenta que los trabajos en un crontab personal (crontab -e ) siempre se ejecutan como su propietario, donde /etc/crontab contiene un <user> obligatorio adicional campo que permite a un administrador configurar el trabajo para que se ejecute como un usuario no raíz.
Editar el crontab del sistema o configurar un crontab personal para root es probablemente un poco más portátil, no específico de ciertas distribuciones de Linux y posiblemente más conveniente para una persona para mantener, con todos los trabajos en un solo archivo pero:
Personalmente prefiero una tercera opción :para cada tarea programada, suelte
- un archivo en
/etc/cron.d/con un fragmento de cron - un ejecutable (script) en el
/etc/cron.[hourly |daily |weekly |monthly]relevante directorio.
Eso es más fácil de escribir (simplemente puede crear/sobrescribir/eliminar dichos archivos y no tiene que perder el tiempo en el contenido de un solo archivo crontab) y funciona bien con las herramientas de administración de configuración y eso es lo que ya son los administradores de paquetes. haciendo de todos modos.
Trabajos/guiones en /etc/cron.[hourly |daily |weekly |monthly] siempre se ejecutan como root, donde los fragmentos de cron en /etc/cron.d/ permitir tanto establecer un horario personalizado como ejecutar como un usuario diferente con el mismo <user> obligatorio campo encontrado en /etc/crontab .
Solución 2:
Según recuerdo, crontab -e tiene la ventaja adicional de que verifica la sintaxis de crontab antes de instalarlo, y generará un error y restaurará el anterior si comete un error. De esta manera, todo lo que funcionaba anteriormente no se detendrá repentinamente si se equivoca en la sintaxis. Creo que la mejor práctica es usar las utilidades, como ejecutar visudo en lugar de editar /etc/sudoers directamente.
Solución 3:
Realmente es una cuestión de estilo, hay una razón por la cual el sistema operativo ofrece múltiples métodos. Solo sea consistente y no mezcle y combine si no quiere confundir a nadie más (o a usted mismo después de un tiempo de no tratar con el sistema); si es difícil ver qué tareas están realmente programadas en todo el host, tiende a para terminar en sorpresas desagradables.
Solución 4:
Para estar seguro de agregar un trabajo cron que requiere derechos de usuario específicos, personalmente uso el siguiente comando:
# crontab -u <user> -e
Puedes agregar sudo también.
Como dijo @rackandboneman, no hay necesidad de meterse con los archivos /etc/cron.d/. Si el asunto es sobre los trabajos cron del usuario, use las características de crontab comando.