| 일정 | 명령 | 설명 | 상태 | 작업 |
|---|---|---|---|---|
0 5 * * * |
/usr/local/bin/custom-backup.sh >> /var/log/arciveo-cron.log 2>&1 |
Nightly backup to remote storage | ||
*/15 * * * * |
/usr/local/bin/healthcheck.sh |
Ping external uptime monitor |
| 명령 | |
|---|---|
30 1 * * * /usr/local/bin/clamav-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 2 * * * /usr/bin/aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1 |
|
@reboot chmod 755 /var/lib/aide |
|
0 3 * * * /usr/local/bin/lynis-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 4 * * * /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
@reboot sleep 60 && /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
30 4 * * * /usr/local/bin/debsums-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 6 * * * /usr/local/bin/logwatch_daily.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 8 * * * /usr/local/bin/daily-report-all.sh >> /var/log/arciveo-cron.log 2>&1 |
|
*/30 * * * * /usr/local/bin/smart-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 * * * * /usr/bin/apt-get update -qq >/dev/null 2>&1 |
|
*/5 * * * * /usr/local/bin/collect-metrics-all.sh >> /var/log/arciveo-cron.log 2>&1 |
cron은 자기 이야기를 하지 않습니다. 작업이 실패했다고 알리지 않고, 마지막으로 언제 돌았는지 보여 주지 않으며, 일정의 다섯 칸에 낸 문법 오류가 드러날 자리도 없습니다. 형식상으로는 로컬 사용자에게 메일을 보내지만, 외부로 나가는 메일을 한 번도 설정하지 않은 서버에서 그 메일을 읽는 사람은 없습니다. 작업은 몇 달이고 망가진 채 있을 수 있고, 그것을 드러내는 것은 결과뿐입니다.
이 페이지는 패널을 통해 추가한 작업을 보여 줍니다. 일정, 명령, 설명, 상태가 나오고 터미널을 열지 않고도 사용하거나 중지하거나 지울 수 있습니다. 그 아래에는 별도 목록으로 root crontab의 나머지 줄, 즉 이전에 사용자나 설치된 패키지가 넣어 둔 줄이 놓입니다. 그쪽은 읽기 전용입니다. 패널은 자기가 쓰지 않은 것을 일부러 건드리지 않습니다.
여기서 확인할 만한 것이 셋 있습니다. 출력이 /dev/null 2>&1로 가는 작업은 잘 돌 때나 망가졌을 때나 똑같이 조용합니다. 전체 경로 대신 짧은 이름으로 적은 명령은 사용자의 셸에서와 다르게 움직입니다. cron에는 아주 빈약한 자체 PATH가 있기 때문입니다. 그리고 일정 자체입니다. 디버깅을 하려고 한 번 꺼 둔 작업은 대개 그대로 꺼진 채 남습니다. 침입이 의심된 뒤에도 cron은 읽어 볼 가치가 있습니다. 스케줄러를 통해 자리 잡는 편이 시작 유닛을 통하는 것보다 쉽고, 그런 줄은 지극히 평범해 보이기 때문입니다.