나는 rsync
수년 동안 그것을 사용해 왔고 이렇게 이상한 문제가 발생한 적이 없습니다. 원격 시스템이 Linux Mint 20을 실행하는 경우를 제외하고 모든 것이 잘 작동합니다(그 중 2개를 시도했는데, 하나는 여전히 20.1을 실행하고 다른 하나는 20.2를 새로 설치했습니다). 단일 파일이든, 전체 디렉터리이든, 아니면 단순한 리소스 목록이든 rsync
관계 없이 협상 후 즉시 중단됩니다("푸시" 또는 "풀" 여부에 관계 없음). 리모컨이 Debian, Armbian 또는 Mint 18인 경우에도 동일한 명령이 제대로 작동합니다(방금 확인하기 위해 오래된 노트북을 열었습니다). 간단한 일이라도
rsync remote:/path/to/file .
걸다. 사용 가능한 디버깅 옵션을 시도한 결과 (SSH 키 또는 비밀번호를 통한) 인증이 제대로 진행되는 것으로 나타났습니다. 잘못된 비밀번호를 입력하면 올바른 "종료"가 표시됩니다. 그러나 올바른 비밀번호/키를 제공하면 인증 직후 세션이 중단되고 더 이상 단서가 제공되지 않습니다. 내가 마지막으로 본 것은 exec request accepted
. ps
원격 시스템에서 사용하면 해당 rsync
프로세스가 생성되었음을 알 수 있습니다(예, 물어보기 전에: SSH를 통해 시스템에 연결하면 제대로 작동하고 심지어 scp
예상대로 작업을 수행하지만 그렇지 않습니다 rsync
).
최후의 수단과 해결 방법으로 rsyncd
원격 시스템에서 임시 작업을 시작했습니다.
rsync --config=/tmp/rsyncd.conf --daemon --no-detach
그런 다음 rsync remote::share/path/to/file
. 이것이 효과가 있고 현재 작업을 완료하는 동안 무언가를 동기화해야 할 때마다 이 작업을 반복하고 싶지 않습니다.
편집하다:
원격지의 일부 출력이 .bashrc
개입할 수 있다고 가정할 수 있습니다. ( ssh remotehost /bin/true > out.dat
맨 페이지에서 확인을 제안한 대로) 0바이트 파일이 생성되므로 이것이 원인이 되어서는 안 됩니다.
strace
원격으로 생성된 프로세스 3개를 실행하면 rsync
(모두 동일한 명령줄이 있습니다. 하나는 선행이고 나머지 두 개는 없음 ) 예상 대로 "클라이언트"( 사용자가 호출함) bash
로 끝나는 것을 알 수 있습니다 . 원격 측의 응답을 기다리고 있을 가능성이 높으므로 1을 표시합니다 .wait4(-1,
{tv_sec=32, tv_usec=23154}
rsync
wait4(-1,
원인이 무엇인지, 이를 해결하는 방법에 대한 아이디어가 있으신가요?어떻게 더 좁힐 수 있나요? 디버깅에 관해서는 제가 사용해본 적이 rsync --debug=all4 -avve "ssh -vvv" …
있는데 이렇게 설명했습니다.
참고로 rsyncd.conf
위의 해결 방법은 다음과 같습니다.
chroot=true 사용 호스트 허용 = 192.168.0.0/24 전송 로깅 = true 로그 파일 = /tmp/rsyncd.log 로그 형식 = %h %o %f %l %b [공유하다] 댓글=공유 경로=/mnt/share 읽기 전용 = 아니요 목록 = 예 uid = 아무도 없음 gid = 그룹 없음
답변1
세 번째 Mint20 시스템을 사용하여 문제를 재현할 수 없었던 후에 범인을 찾았습니다. 이는 Mint20 시스템 중 하나가 "서버"로 참여하여 검색 범위를 좁힐 때만 발생하는 것으로 나타났습니다. which rsync
그곳으로 달려가서 /usr/local/bin/rsync
돌아왔습니다. 이것은 ("서버" 측에 표시된 네 번째 rsync 프로세스와 함께, 정기적으로 실행하는 다른 프로세스에 속한다고 생각했기 때문에 무시했습니다) 다음과 같이 진행되었습니다.
/usr/local/bin/rsync
직업을 중심으로 배열되다동기화 오류이 문제는 2006년부터 알려져 왔으며 아직 수정되지 않았습니다.스크립트는 여기에 있습니다). 기계가 클라이언트로만 사용되었기 때문에 이 성가신 문제를 해결하기 위해 수년 동안 잘 작동했지만 이제 기계를 교체해야 하고 전송을 위해 서버 역할을 해야 하므로 비생산적입니다.
현재의 문제뿐만 아니라 원래의 문제를 해결하기 위해 스크립트를 PATH
활성 사용자의 디렉터리로만 옮겼지만,아니요 root
(리모컨은 rsync
항상 루트에 의해 생성되며 원본을 가져와야 합니다 /usr/bin/rsync
). 모든 방향으로 테스트한 후 작동하는 것 같습니다(원래 해결 방법을 적용한 "해당 cron 작업"을 기다리면 됩니다).
추신: rsync-no-vanished
이 스크립트를 사용하는 경우 약간만 조정하면 문제가 해결될 것입니다. 스크립트를 다음과 같이 변경하세요.
if [[ $(id -u) -eq 0 ]]; then
/usr/bin/rsync $@
else
# original "rsync-no-vanished" script in here
fi
이렇게 하면 루트(예: 생성된 원격)에서 호출할 때 원본 rsync
바이너리만 참조하고 클라이언트가 호출한 "해결 방법"만 사용합니다.
첨부된:세부 사항과 제안된 수정 사항을 가지고 프로젝트에 연락한 후 스크립트곧 업데이트됩니다이렇게 하면 앞으로 유사한 상황을 피할 수 있습니다(즉각적인 답변을 주신 Wayne에게 감사드립니다!).