Bug 664075 - rsync frozen, syncing a drive mounted in media with a home directory tree
Summary: rsync frozen, syncing a drive mounted in media with a home directory tree
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rsync
Version: 14
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Vojtech Vitek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-17 23:03 UTC by giampaolo ferradini
Modified: 2015-03-04 23:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-08 07:51:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description giampaolo ferradini 2010-12-17 23:03:40 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.2.13) Gecko/20101209 Fedora/3.6.13-1.fc14 Firefox/3.6.13

the drives are both ext4, and was rsyncing music files, when rsync got frozen. it could still respond to ^C.  see last few lines of syncing report and after ^C in the additional info field.

several attempts, always freezing in the same place, while handling the same directory and files.
initially thought it might have been due to non utf8 characters in the file names, but even after removing them it still could not sync them.

the command was executed as root, and syntax used was:
rsync -r -t -p -o -g -v --progress --delete -c -i -vvv /media/giampy2/musica/ /home/giampy/musica/
where giampy2 is a secondary drive in the pc
the directories had already been synced successfully in the past few days, but within a larger rsync command, i.e.:
rsync -r -t -p -o -g -v --progress --delete -c -i -vvv /media/giampy2/ /home/giampy/

Reproducible: Always

Steps to Reproduce:
1.mounting disk giampy2
2.su
3.rsync -r -t -p -o -g -v --progress --delete -c -i -vvv /media/giampy2/musica/ /home/giampy/musica/
Actual Results:  
after syncing between 15% and one third of the files it just freezes always at the same spot. it does accept ^C and stops execution.
looking at the directory structure, it appears that nothing has been done (dirs that should have been synced are still in the old form)

Expected Results:  
it should have completed syncing

here are the last files synced and the exit report (after ^C)

[sender] i=975 /media/giampy2/musica Compilations/Best Seller All'italiana/09 Toto Cutugno - Volo AZ 504.m4a mode=0100644 len=23037092 uid=500 gid=500 flags=0
[sender] i=976 /media/giampy2/musica Compilations/Best Seller All'italiana/10 Matia Bazar - Solo Tu.m4a mode=0100644 len=22440633 uid=500 gid=500 flags=0
[sender] i=977 /media/giampy2/musica Compilations/Best Seller All'italiana/11 Massimo Ranieri - Erba Di Casa Mi.m4a mode=0100644 len=24474919 uid=500 gid=500 flags=0
[sender] i=978 /media/giampy2/musica Compilations/Best Seller All'italiana/12 Christian - Mia Bella Signora.m4a mode=0100644 len=24290656 uid=500 gid=500 flags=0
[sender] i=979 /media/giampy2/musica Compilations/Best Seller All'italiana/13 Sandro Giacobbe - Signora Mia.m4a mode=0100644 len=25955828 uid=500 gid=500 flags=0
[sender] make_file(Compilations/Cabaret 1/05 Ma Chi E' Quella La.m4a,*,2)
[sender] make_file(Compilations/Cabaret 1/06 Però Mi Vuole Bene.m4a,*,2)
[sender] make_file(Compilations/Cabaret 1/11 Fammi Un Panino.m4a,*,2)
[sender] make_file(Compilations/Cabaret 1/09 Giovanni Telegrafista.m4a,*,2)
^C[sender] _exit_cleanup(code=20, file=rsync.c, line=545): entered
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(545) [sender=3.0.7]
[sender] _exit_cleanup(code=20, file=rsync.c, line=545): about to call exit(20)
rsync: writefd_unbuffered failed to write 71 bytes to socket [Receiver]: Broken pipe (32)
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(545) [Receiver=3.0.7]
[Receiver] _exit_cleanup(code=20, file=rsync.c, line=545): about to call exit(20)

Comment 1 giampaolo ferradini 2011-03-08 07:51:02 UTC
i suspect the bug is related to permissioning, although --being quite inexperienced-- could not figure exactly why.
running the rsync script as root solves the problem.


Note You need to log in before you can comment on or make changes to this bug.