서버에는 일부 파일을 생성하고 /tmp완료되면 삭제하지 않는 정규 작업이 있습니다. 들어가고 싶지 않은 이유로 작업을 수정하여 파일을 삭제할 수 없습니다. 그래서 주기적으로 이러한 파일을 삭제하는 cronjob을 만들고 싶습니다. 작업 실행을 방해하지 않으려면 하루가 지난 파일만 삭제해야 합니다. 나는 다음 명령을 생각해 냈습니다.
find /tmp/myprefix* -mtime +1 -delete
터미널에서 테스트하면 잘 작동하므로 cron으로 예약합니다.
0 1 * * * find /tmp/myprefix* -mtime +1 -delete
이제 오전 1시에 실행하면 -mtime매개변수를 무시하고 로 시작하는 모든 파일을 삭제하여 myprefix실행 중인 작업을 방해하는 것으로 보입니다.
왜 이런 일이 일어나는지 아는 사람이 있나요?
참고: 작업은 밤에만 실행되므로 작업 실행 없이 모든 테스트가 실행됩니다. 어젯밤에 완료한 작업에 대한 파일이 아직 거기에 있는지 방금 확인했습니다. 어쩌면 그게 이유이고 파일이 아직 기록되는 동안 파일 수정 시간이 이상한 방식으로 설정되어 있는 것일까요?
낮 시간에 청소를 예약하는 것이 확실한 해결책이라는 것을 알지만, 여전히 문제의 원인에 관심이 있습니다.
편집하다
Kusalanandas의 제안에 따라 어젯밤의 크론 항목을 다음과 같이 변경했습니다.
0 1 * * * find /tmp/myprefix* -mtime +1 -ls > /tmp/find.out
/tmp/find.out오늘 아침에는 파일이 비어 있었습니다. 이는 오래된 파일이 없기 때문에 예상되는 동작입니다. 그러나 과거 관찰에 따르면 -delete"너무 어린" 파일로 실행하면 삭제됩니다.
편집 2
마지막 테스트를 마친 후 두 번째 밤의 명령을 다음으로 변경했습니다.
0 1 * * * find /tmp/myprefix* -mtime +2 -delete
예상 대로 +2전날 밤에 생성된 파일은 삭제되지 않았습니다. 파일은 남아 있었지만 오늘 밤의 파일은 삭제되었습니다. 이제 -mtime파일이 아직 작성 중이면 검사가 예상대로 실행되지 않을 것이라고 확신합니다 . -ls전날 밤에 아무것도 출력되지 않은 이유는 여전히 미스터리입니다 . 어쩌면 다시 실행해보고 -exec자세한 ls내용을 알아봐야겠습니다. 그런데 2주간의 휴가를 앞두고 한 번 더 도전해보겠습니다 :-)
답변1
cron 항목은 또 다른 bash 라인처럼 보이지만 그렇지 않습니다. find 구문을 별도의 스크립트에 넣고 실행해 보세요. 예를 들면 다음과 같습니다.
echo "find /tmp/myprefix* -mtime +1 -delete" > /my/path/cronscript.sh chmod 755 /my/path/cronscript.sh
cron 라인을 다음과 같이 편집합니다. 0 1 * * * /my/path/cronscript.sh
일부 조정도 필요할 수 있습니다. chown / chgrp또한 /etc/crontab아카이브에서 작업하는 경우 username추가 정보가 필요합니다.0 1 * * * username /my/path/cronscript.sh