제가 일하는 곳에서는 Debian Wheezy를 실행하는 중앙 백업 서버가 있고 각 사이트에 Debian Wheezy를 실행하는 온사이트 서버가 있습니다.
몇 주 전, 중앙 사무실 기술자가 저에게 이메일을 보내 전날 밤 백업이 제대로 완료되지 않았다고 말했습니다. 그 이후로 문제를 해결해 왔지만 여전히 문제를 해결할 수 없는 것 같습니다. 유일한 반박은 cron
이메일에서 다음과 같습니다.
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [generator=3.0.9]
rsync error: received SIGUSR1 (code 19) at main.c(1316) [receiver=3.0.9]
이 문구를 인터넷 검색해 보면 거의 아무것도 나오지 않습니다. 삭제 스위치에 대한 2002년 게시물을 찾았 -v
지만 스크립트에서는 사용되지 않습니다. 매일 밤 실행되는 스크립트는 다음과 같습니다.
#!/bin/sh
set -e
x="delete --exclude-from=r_filter --delete-excluded"
rsync -aq --$x site1.company.com:/etc /BACKUPS/site1
rsync -aq --$x site1.company.com:/home /BACKUPS/site1
월요일부터 금요일까지 오전 3시에 중앙 백업 서버에서 실행되도록 설정되어 있습니다. 낮에 수동으로 실행하려고 하면 제대로 작동합니다(대부분의 파일이 이전에 백업되었기 때문에?). 스위치를 사용하므로 -a
열린 파일을 보관할 수 있다고 가정합니까? 그게 내가 생각할 수 있는 전부입니다.
이 문제를 해결하기 위한 다음 단계는 무엇입니까?
답변1
테스트를 위해 1분 이내에 작업을 실행할 때 발생하지 않는 특정 시간에 crontab에서 작업을 실행할 때 발생하는 경우 두 가지 가능성이 있습니다.
- crontab에는 어떤 방식으로든 프로세스를 방해하는 또 다른 프로세스가 있습니다.
- 청소 직원이 진공 청소기를 연결하기 위해 컴퓨터의 플러그를 뽑는 것처럼 인간의 프로세스가 진행되고 있었습니다.
rsync 프로세스는 밤 중 어느 시점에 신호를 수신합니다. 내가 가장 먼저 찾아야 할 것은 crontab의 다른 프로세스가 보내서는 안되는 신호를 보내는지 여부입니다.
(명령줄에서 실행하면 잘 작동하지만 cron에서 실행할 때 실패하는 경우,이건 완전히 다른 생선 냄비예요.)
답변2
이러한 일이 다시 발생하지 않도록 명령을 신호의 영향을 받지 않게 만드는 동시에 동일한 프로세스 그룹의 일부 상위 프로세스를 통해 쉘로 전달되는 경우 백그라운드에서 신호를 포착할 수 있습니다. 예를 들어:
#!/bin/bash
( trap 'echo got signal; date; ps ax; kill $pid; exit' sigint sigterm sighup
sleep 999999 &
pid=$!
wait
) &
trap '' sigint sigterm sighup
rsync ...
rsync ...
kill -hup $!
trap ''
다음 명령에 나열된 3개의 신호 는 무시 됩니다 . 의 배경 부분은 ()
신호를 포착하고 예를 들어 ps
그 순간에 실행 중인 항목을 찾는 것과 유사한 작업을 수행합니다.
logrotate
나는 이것을 신호하는 지나치게 열정적인 명령 과 같은 어리석은 것을 찾을 것입니다 .