방금 SVN 저장소를 작성한 자동화 된 덤프가 초기에 중단되었고 기본적으로 덤프의 절반 만이 발견되었습니다. 비상 사태는 아니지만 나는이 상황에 처한 것이 싫다. 자동 백업을 처음부터 만드는 목적을 무효화합니다.CRONTAB이 svndump를 완료하지 않음
사용중인 명령은 다음과 같습니다. 터미널에서 수동으로 실행하면 정상적으로 완료됩니다. output.txt 파일은 크기가 16 메가이고 335 개정입니다. 그러나 내가 crontab에 남겨두면 중도에서 약 8.1 메가와 169 개의 개정판 만 남게됩니다.
# m h dom mon dow command
18 00 * * * svnadmin dump /var/svn/repos/myproject > /home/andrew/output.txt
내가 실제로 일자 gzip으로 압축 된 파일에 저장하고, 서버 공간의 부족이 없다, 그래서 이것은 디스크 공간 문제가되지 않습니다. 2 초 후에 보석금을 지급하는 것으로 보입니다. 시간 문제 일 수 있지만 파일 크기는 지난 한 달에 한 번씩 동일하므로 그 중 하나라고 생각하지 않습니다. crontab은 제한된 메모리 공간 내에서 실행됩니까?
크기 제한이 여기에 중요한 요소라고 생각하지 않습니다. 파일이 절반 정도 잘려나 갔지만 디렉토리에는 동일한 크기의 20 개의 동일한 백업이있었습니다. 나는/tmp로 덤프를 시도하고 같은 지점에서 잘렸다. crontab은 수퍼 유저 레벨에서 실행되기 때문에 파일 시스템에 대해 꽤 자유로운 액세스가 있어야합니다. – Andrew
다른 생각 : - svnadmin 호출을 쉘 scrtipt로 랩핑 해보십시오. svnadmin 호출 전후의 날짜/시간 스탬프를 추가하십시오. 출력을 일부 로그 파일로 재 지정하십시오. 또한 svnadmin 결과 코드를 기록하십시오. 이것은 당신에게 svnadmin의 호출이 얼마나 성공적 이었는지 그리고 얼마나 오래 걸렸는 지에 대한 약간의 아이디어를 줄 것입니다. - 다른 시간에이 작업을 다시 예약하십시오 (특정 날짜 및 실행 시간과 관련된 일부 미친 cron 버그가 있습니다). – sha
물론 쉘 스크립트에서 리턴 코드를 캡쳐 할 때 svnadmin dump는 수동으로 sudo를 실행할 때 "0"으로 돌아 오지만 crontab에서 "1"로 돌아옵니다. 나는 또한/usr/bin/id를 기록했으며 me와 crontab에 대한 정보가 동일하다. 스크립트가 동일한 사용자 컨텍스트에서 실행 중입니다. 여기에 표시되지 않는 crontab 구성 값이 있어야합니다.이 중 어느 것도 나에게 어떤 의미가 없습니다. 나는 파기를 계속할 것이다. – Andrew