Se um crontab de root criado com crontab -e desaparecer após um reinício do ZimaOS, esse comportamento é compatível com a estrutura do sistema do ZimaOS, semelhante à de um dispositivo, e maioritariamente só de leitura. O tópico de novembro de 2025 identificou corretamente o sintoma, mas apresentou apenas uma solução genérica baseada num contentor.
Existe agora uma opção mais nativa do ZimaOS: o pacote Zima Cron, mantido pela comunidade, pode ser instalado com zpkg e armazena a configuração das tarefas agendadas de uma forma concebida para o ZimaOS.
Porque desapareceu o antigo crontab de root
O utilizador criou uma entrada cron para root, confirmou-a com crontab -l e depois perdeu a entrada após o reinício. Uma resposta da comunidade explicou que as configurações persistentes devem ficar no armazenamento persistente do ZimaOS, e não nos caminhos normais e mutáveis do sistema Linux.
Essa explicação está de acordo com as orientações atuais do ZimaOS, segundo as quais a maioria das pastas do sistema é só de leitura e os dados dos utilizadores e das aplicações devem ficar em /DATA.
Utilize o Zima Cron em vez de reconstruir o estado de /var/spool
O atual tutorial do Zima Cron documenta zpkg install zima_cron, após o qual o Zima Cron aparece na lista de aplicações. Suporta agendamentos por intervalos e expressões cron normais.
Mantenha os scripts e os ficheiros de saída em /DATA, para que a própria tarefa não dependa de um caminho temporário do sistema.
Teste a persistência antes de confiar numa tarefa de cópia de segurança real
Comece por criar uma tarefa inofensiva — por exemplo, adicionar a hora atual a um registo em /DATA. Confirme que é executada, reinicie o ZimaOS e, em seguida, confirme que a tarefa continua a existir e que continua a registar novas marcas temporais.
Só depois disso deverá transferir um comando de cópia de segurança, limpeza ou sincronização para o agendador. O guia de resolução de problemas de tarefas agendadas aborda a camada seguinte, quando o agendador sobrevive, mas o próprio comando não é executado.
Quando continua a fazer sentido utilizar um contentor de agendamento
Um contentor de agendamento dedicado continua a ser uma opção razoável quando a tarefa pertence a uma determinada pilha de aplicações e deve ser versionada com a respetiva configuração do Compose. Nesse caso, torne a configuração persistente e atribua claramente a responsabilidade pelo agendamento a um único componente.
O guia de persistência do Docker ajuda a evitar colocar scripts dentro de uma camada descartável do contentor.
Conclusão
Não dependa de um crontab do sistema editado manualmente como camada de agendamento persistente no ZimaOS. Coloque os scripts e os registos em /DATA, utilize o Zima Cron ou outro agendador deliberadamente persistente e certifique-se de que o agendamento sobrevive tanto a um reinício do ZimaOS como à recriação de uma aplicação ou de um contentor.
