La compatibilidad de ZimaOS con las tareas programadas evolucionó varias veces después de que comenzara este hilo. En febrero de 2025, los usuarios creaban temporizadores systemd personalizados porque no había una interfaz de cron cómoda. En marzo, Zima-Giorgio anunció que dcron se añadiría y posteriormente se dijo que estaba incluido en la beta 1.4.0. En 2026, IceWhale publicó un tutorial de Zima Cron utilizando el gestor de paquetes de módulos de ZimaOS, mientras que desarrolladores de la comunidad reescribieron posteriormente el programador para mejorar la persistencia y añadir una interfaz web completa.
La lección práctica no es «instalar cron con apt». ZimaOS es un sistema operativo de dispositivo inmutable. Elige un método de programación que sobreviva al ciclo de vida que realmente necesitas —reinicio, actualización OTA, reinicio del módulo— y prueba esa persistencia antes de confiarle copias de seguridad o tareas de mantenimiento destructivas.
Los usuarios de la fuente querían más de un tipo de tarea programada
Los casos de uso incluían:
- reinicio diario;
- cada hora
chmod/chownscripts; - tareas en segundo plano y actualizaciones RSS de Nextcloud;
- scripts de copias de seguridad programadas;
- pruebas S.M.A.R.T.;
- tareas nocturnas de SnapRAID;
- acciones de inicio que entren en conflicto con Pi-hole.
No todos estos casos se resuelven igual de bien con un solo programador. Las dependencias de los servicios de inicio suelen gestionarse mejor con systemd, mientras que los comandos periódicos del usuario encajan en una programación de estilo cron.
Los temporizadores systemd de la comunidad funcionaron y sobrevivieron al menos a algunas actualizaciones
WuzzyFeasel creó un temporizador de reinicio en /etc/systemd/system/ y posteriormente informó de que los temporizadores systemd personalizados sobrevivieron a una actualización de ZimaOS. Fue una validación útil por parte de la comunidad.
Zima-Giorgio también recomendó específicamente systemd para un trabajo de inicio cuando un usuario quería que ciertas tareas relacionadas con Pi-hole se ejecutaran después del arranque.
IceWhale anunció dcron para ZimaOS 1.4.0
El 5 de marzo de 2025, Zima-Giorgio escribió: “se añadirá dcron”. En abril aclaró que dcron estaba incluido en la beta 1.4.0 y que se añadiría a la versión estable.
Esta es una declaración histórica oficial del producto, no una suposición de la comunidad.
Tener crontab disponible no garantizaba la persistencia de los trabajos del usuario
Más adelante, usuarios de la versión 1.5.x informaron que las entradas de crontab desaparecían tras reiniciar o que las tareas del programador no persistían de forma fiable. Por eso, simplemente ver un crontab el comando no demuestra que los trabajos guardados del usuario sobrevivan al ciclo de vida del sistema inmutable.
Reinicia siempre una vez y verifica que la tarea siga existiendo antes de depender de ella.
IceWhale publicó posteriormente un tutorial del módulo Zima Cron
En enero de 2026, 777-Spider publicó un tutorial independiente sobre Zima Cron utilizando:
zpkg install zima_cronEl tutorial incluía programación por intervalos y mediante expresiones cron, además de registros de tareas. Era un programador a nivel de módulo, no un paquete de Debian instalado con APT.
Consulta el flujo de trabajo del módulo Zima Cron y su debate posterior antes de dar por sentado que un nombre o una versión específicos del módulo siguen vigentes.
Una reescritura comunitaria de Cron añadió una interfaz completa de planificación
La reescritura v0.2.0 de Lintux anunciaba tareas persistentes, plantillas, registros, notificaciones, reintentos, dependencias, prioridades y etiquetas. Se distribuía como un cron.raw módulo y podía instalarse con zpkg.
Este módulo es software comunitario, no es lo mismo que la implementación original de dcron de IceWhale.
ZimaOS 1.6.1 corrigió un problema de reinicio del servicio de los módulos
Las notas de la versión 1.6.1 de IceWhale incluyen una corrección para un problema por el que los módulos mod no iniciaban los servicios según la política de servicio después de un reinicio. Esto es relevante para los módulos de planificación que deben reactivarse automáticamente después de reiniciar.
No demuestra que hayan desaparecido todos los errores históricos de persistencia de Cron; establece que hubo una corrección posterior de la plataforma para el comportamiento de inicio del servicio del módulo.
No uses un planificador no probado como único controlador de copias de seguridad
Una copia de seguridad programada solo es útil si:
- la tarea persista después de un reinicio/actualización;
- el destino esté montado;
- el comando devuelva un estado significativo;
- se conserven los registros;
- se haya probado una restauración.
Automatizar un script que detenga todos los contenedores también provoca una interrupción y puede dejar los servicios detenidos si el script falla a mitad de la ejecución.
Cambiar chmod/chown cada hora suele ser un síntoma, no la mejor solución a largo plazo
El autor de la publicación original quería cambiar los propietarios cada hora porque la aplicación multimedia no podía leer los archivos copiados desde Windows. Un diseño mejor consiste en corregir los permisos de usuario/grupo de SMB y los permisos de UID/GID/montaje del contenedor, para que los archivos nuevos se creen desde el principio con un acceso utilizable.
Un planificador que aplique repetidamente cambios recursivos de propietario puede ser lento y dañar los permisos que otra aplicación necesita.
¿Qué planificador deberías usar?
- Dependencia de arranque/inicio: cuando corresponda, prioriza un servicio/temporizador de systemd correctamente diseñado.
- Tarea periódica sencilla: usa un planificador/módulo disponible y compatible con tu versión actual de ZimaOS.
- Flujo de trabajo complejo: considera usar un contenedor de automatización específico, pero prueba la persistencia tras los reinicios y la seguridad del socket de Docker.
Preguntas frecuentes sobre Cron de ZimaOS
¿Dijo IceWhale oficialmente que se añadiría dcron?
Sí. Zima-Giorgio dijo que se incluyó en la beta 1.4.0 y que estaba previsto incorporarla a la versión estable.
¿Persistió tras los reinicios cada tarea posterior de crontab?
No. Varios usuarios posteriores informaron de la pérdida de tareas o de problemas de persistencia del planificador.
¿La interfaz de usuario oscura de Scheduler de 2026 es una función integrada de IceWhale?
Proviene de una reescritura comunitaria del módulo Cron y debe tratarse como software de terceros.
