이 스레드가 시작된 이후 ZimaOS의 예약 작업 지원은 여러 차례 발전했습니다. 2025년 2월에는 편리한 cron UI가 없었기 때문에 사용자들이 사용자 지정 systemd 타이머를 만들고 있었습니다. 3월에 Zima-Giorgio는 다음과 같이 발표했습니다. dcron 추가될 예정이라고 했다가 이후 1.4.0 베타에 포함되었다고 밝혔습니다. 2026년에는 IceWhale이 ZimaOS 모듈 패키지 관리자를 사용하는 Zima Cron 튜토리얼을 게시했으며, 이후 커뮤니티 개발자들은 지속성을 개선하고 완전한 웹 인터페이스를 추가하기 위해 스케줄러를 다시 개발했습니다.
실질적인 교훈은 “apt로 cron을 설치하라”가 아닙니다. ZimaOS는 불변 어플라이언스 OS입니다. 재부팅, OTA 업데이트, 모듈 재시작 등 실제로 필요한 수명 주기 동안 유지되는 스케줄링 방법을 선택하고, 백업이나 파괴적인 유지 관리 작업을 맡기기 전에 해당 지속성을 테스트하세요.
소스의 사용자들은 한 가지 이상의 예약 작업 유형을 원했습니다
사용 사례에는 다음이 포함되었습니다.
- 매일 재부팅;
- 매시간
chmod/chown스크립트; - Nextcloud 백그라운드 작업 및 RSS 업데이트;
- 예약된 백업 스크립트;
- S.M.A.R.T. 테스트;
- 매일 밤 실행되는 SnapRAID 작업;
- Pi-hole 충돌을 위한 시작 작업.
이 작업들은 하나의 스케줄러로 모두 동일하게 처리하기 어렵습니다. 시작 서비스 종속성은 systemd로 처리하는 편이 더 나은 경우가 많고, 주기적인 사용자 명령은 cron 방식의 스케줄링에 적합합니다.
커뮤니티 systemd 타이머는 적어도 일부 업데이트에서 작동했고 유지되었습니다
WuzzyFeasel은 다음 위치에 재시작 타이머를 만들었습니다. /etc/systemd/system/ 이후 사용자 지정 systemd 타이머가 ZimaOS 업데이트 후에도 유지된다는 보고도 있었습니다. 이는 유용한 커뮤니티 검증이었습니다.
Zima-Giorgio는 사용자가 Pi-hole 관련 작업을 부팅 후 실행하려 했을 때 시작 작업에 특히 systemd를 사용할 것을 권장하기도 했습니다.
IceWhale, ZimaOS 1.4.0에 dcron 추가 예정 발표
2025년 3월 5일, Zima-Giorgio는 다음과 같이 작성했습니다. “dcron이 추가될 예정입니다.” 4월에는 dcron이 1.4.0 베타에 포함되었으며 안정 버전에 추가될 것이라고 설명했습니다.
이는 커뮤니티의 추측이 아니라 공식적인 과거 제품 설명입니다.
crontab을 사용할 수 있다고 해서 사용자 작업이 지속된다는 보장은 없었습니다
이후 1.5.x 사용자들은 재부팅 후 crontab 항목이 사라지거나 스케줄러 작업이 안정적으로 유지되지 않는다고 보고했습니다. 따라서 단순히 crontab 명령어만으로는 사용자가 저장한 작업이 불변 시스템의 수명 주기 동안 유지된다는 것을 입증할 수 없습니다.
항상 한 번 재부팅한 후에도 작업이 계속 존재하는지 확인하고, 그 결과를 확인하기 전에는 해당 작업에 의존하지 마세요.
IceWhale, 이후 Zima Cron 모듈 튜토리얼 게시
2026년 1월, 777-Spider는 다음을 사용하는 Zima Cron 관련 별도의 튜토리얼을 게시했습니다.
zpkg install zima_cron이 튜토리얼에는 간격 및 cron 표현식 기반 예약과 작업 로그가 포함되어 있었습니다. 이는 APT로 설치하는 Debian 패키지가 아니라 모듈 수준의 스케줄러였습니다.
특정 모듈 이름이나 버전이 여전히 최신이라고 가정하기 전에 Zima Cron 모듈의 워크플로와 이후 논의를 확인하세요.
커뮤니티 Cron 재작성 버전이 완전한 Scheduler UI를 추가했습니다
Lintux의 v0.2.0 재작성 버전은 지속적인 작업, 템플릿, 로그, 알림, 재시도, 종속성, 우선순위 및 태그를 지원한다고 홍보되었습니다. 이는 다음 형식으로 배포되었습니다. cron.raw 모듈이며 다음 명령으로 설치할 수 있었습니다. zpkg.
이 모듈은 커뮤니티 소프트웨어이며 IceWhale의 기존 dcron 구현과는 다릅니다.
ZimaOS 1.6.1에서 모듈 서비스 재부팅 문제가 수정됨
IceWhale의 1.6.1 릴리스 노트에는 재부팅 후 mod 모듈이 서비스 정책에 따라 서비스를 시작하지 않던 문제의 수정 사항이 포함되어 있습니다. 이는 재시작 후 자동으로 다시 실행되어야 하는 스케줄러 모듈과 관련이 있습니다.
모든 과거 Cron 지속성 버그가 사라졌다는 뜻은 아니며, 모듈 서비스 시작 동작에 대한 이후 플랫폼 수정이 이루어졌음을 의미합니다.
테스트하지 않은 스케줄러를 유일한 백업 제어 수단으로 사용하지 마세요
예약된 백업은 다음 조건을 충족할 때만 유용합니다.
- 작업이 재부팅/업데이트 후에도 유지됩니다.
- 대상 위치가 마운트되어 있습니다.
- 명령이 의미 있는 상태를 반환합니다.
- 로그가 보존됩니다.
- 복원이 테스트되었습니다.
모든 컨테이너를 중지하는 스크립트를 자동화하면 서비스 중단이 발생하며, 스크립트가 중간에 실패할 경우 서비스가 중지된 채로 남을 수 있습니다.
매시간 chmod/chown을 실행하는 것은 대개 증상일 뿐, 장기적으로 가장 좋은 해결책은 아닙니다
원 게시자는 Windows에서 복사한 파일을 미디어 앱이 읽을 수 없어서 매시간 소유권을 변경하려고 했습니다. 더 나은 방법은 SMB 사용자/그룹 권한과 컨테이너 UID/GID 및 마운트 권한을 수정하여 새 파일이 처음부터 사용할 수 있는 접근 권한으로 생성되도록 하는 것입니다.
소유권 변경을 반복적으로 재귀 적용하는 스케줄러는 느릴 수 있으며 다른 애플리케이션이 요구하는 권한을 손상시킬 수 있습니다.
어떤 Scheduler를 사용해야 하나요?
- 부팅/시작 종속성: 적절한 경우 제대로 설계된 systemd 서비스/타이머를 우선 사용하세요.
- 단순한 주기적 작업: 현재 사용 중인 ZimaOS 릴리스에서 사용할 수 있고 지원되는 스케줄러/모듈을 사용하세요.
- 복잡한 워크플로: 전용 자동화 컨테이너를 고려하되, 재부팅 후 작업 지속성과 Docker 소켓 보안을 테스트하세요.
ZimaOS Cron FAQ
IceWhale이 dcron을 추가하겠다고 공식적으로 밝혔나요?
예. Zima-Giorgio는 이것이 1.4.0 베타에 포함되었으며 정식 버전에도 적용할 예정이라고 말했습니다.
이후 추가된 모든 crontab 작업이 재부팅 후에도 유지되었나요?
아니요. 이후 여러 사용자가 작업 유실 또는 스케줄러 지속성 문제를 보고했습니다.
2026년의 어두운 테마 Scheduler UI는 IceWhale의 기본 제공 기능인가요?
커뮤니티에서 Cron 모듈을 재작성한 것으로, 서드파티 모듈 소프트웨어로 취급해야 합니다.
