2010-02-24 8 views
2

방금 ​​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은 제한된 메모리 공간 내에서 실행됩니까?

답변

5

그래서 실제 문제는 무엇인지 모르겠지만 덤프를 할 때 svnadmin의 STDERR을/dev/null로 라우팅하면 모든 것이 잘됩니다. "조용한"플래그 (-q)를 사용하여 시도해 보았습니다. 나는 crontab에서 실행중인 쉘 스크립트가 STRERR에서 충분한 텍스트를 만났을 때 실행중인 모든 것을 실행을 중지하고 다음 명령으로 간다고 가정합니다. MD5를 수동 파일과 예약 파일로 작성했는데 그 파일은 동일합니다. 이것은 해결 된 것으로 보인다. 그래서 누군가가이 문제를 직접 경험한다면, 이것은 초기 절단을 성공적으로 통과하기 위해 사용한 쉘 스크립트입니다. 조금 장황하다. 죄송합니다.

#!/bin/sh 
echo "STARTING AT $(date +\%Y/\%m/\%d/T%I:\%M:\%S)" >> /home/andrew/svnlog.txt 
rm /tmp/andrewMobileApp.dump 
svnadmin dump /var/svn/repos/andrewMobileApp > /tmp/andrewMobileApp.dump 2>/dev/null 
echo "svnadmin exited with code $?" >> /home/andrew/svnlog.txt 
gzip -c /tmp/andrewMobileApp.dump > "/home/andrew/svnbackups/andrewMobileApp.dump.$(date +\%Y\%m\%d\%I\%M\%S).txt.gz" 
echo "gzip exited with code $?" >> /home/andrew/svnlog.txt 
echo "DONE AT $(date +\%Y/\%m/\%d/T%I:\%M:\%S)" >> /home/andrew/svnlog.txt 
echo "-----" >> /home/andrew/svnlog.txt 

이 스크립트는 수퍼 유저 crontab을 통해 호출됩니다.

0

사용자 디렉토리의 크기 제한이 있습니까? 먼저 임시 직원에게 덤프하려고 할 수도 있습니다.

+0

크기 제한이 여기에 중요한 요소라고 생각하지 않습니다. 파일이 절반 정도 잘려나 갔지만 디렉토리에는 동일한 크기의 20 개의 동일한 백업이있었습니다. 나는/tmp로 덤프를 시도하고 같은 지점에서 잘렸다. crontab은 수퍼 유저 레벨에서 실행되기 때문에 파일 시스템에 대해 꽤 자유로운 액세스가 있어야합니다. – Andrew

+0

다른 생각 : - svnadmin 호출을 쉘 scrtipt로 랩핑 해보십시오. svnadmin 호출 전후의 날짜/시간 스탬프를 추가하십시오. 출력을 일부 로그 파일로 재 지정하십시오. 또한 svnadmin 결과 코드를 기록하십시오. 이것은 당신에게 svnadmin의 호출이 얼마나 성공적 이었는지 그리고 얼마나 오래 걸렸는 지에 대한 약간의 아이디어를 줄 것입니다. - 다른 시간에이 작업을 다시 예약하십시오 (특정 날짜 및 실행 시간과 관련된 일부 미친 cron 버그가 있습니다). – sha

+0

물론 쉘 스크립트에서 리턴 코드를 캡쳐 할 때 svnadmin dump는 수동으로 sudo를 실행할 때 "0"으로 돌아 오지만 crontab에서 "1"로 돌아옵니다. 나는 또한/usr/bin/id를 기록했으며 me와 crontab에 대한 정보가 동일하다. 스크립트가 동일한 사용자 컨텍스트에서 실행 중입니다. 여기에 표시되지 않는 crontab 구성 값이 있어야합니다.이 중 어느 것도 나에게 어떤 의미가 없습니다. 나는 파기를 계속할 것이다. – Andrew

1

먼저 svnadmin이 cron 작업의 PATH 환경 변수에 있는지 확인하십시오. /usr/bin/svnadmin 또는 적절한 경로를 지정해야 할 수 있습니다.

또한 svnadmin dump이 아닌 svnadmin hotcopy은 저장소의 백업을위한 도구입니다.

+0

절대 경로를 추가하려고 시도했지만 아무런 차이가 없습니다. svnadmin _is_ executing을 실행하면 완료되지 않는 것 같습니다. 나는 휴대용이 아니기 때문에 hotcopy 사용을 피하고 싶었다. 저장소의 덤프를 잡아 (잠재적으로) 하드웨어 장애 발생시 서버의 야간 스냅 샷을 생성하는 데 사용할 수 있습니다. 어쨌든 그 아이디어입니다. – Andrew

+0

명령의 표준 오류를 파일로 캡처하여 오류를보고하는지 확인할 수 있습니다. – Avi

+0

예외 또는 오류가 표시되지 않습니다. 2 월 24 일 01:12:01 desktop/USR/SBIN/CRON [25399] : (루트) CMD (/ usr/bin/svnadmin dump/var/svn/repos/myproject> /home/andrew/output.txt) 필자는 명령문의 끝에 '&'를 추가하여 실행 시간을 늘릴 수 있는지 확인하려고 시도했습니다. 그것이 crontab에서도 의미가 있는지는 확실하지 않지만 아무 효과가 없습니다. – Andrew

1

데비안 크론 패키지에 가상 서버 (virtual server) 아래에서 발생했기 때문에 이것을 버그로 제출했습니다. 데비안의 버그 # 577133을 참조하십시오. Christian Kastner는 MTA가 발견되지 않으면 모든 메일 처리 코드를 우회하는 코드를 추가하여 버그를 패치했습니다.

관련 문제