[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible bug -- how to trace the dead-lock?
From: |
Maciej Pilichowski |
Subject: |
Re: Possible bug -- how to trace the dead-lock? |
Date: |
Mon, 20 Dec 2010 08:34:44 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 |
Hi,
Before I forget :-), I am subscriber, so don't CC to me.
To have people on the email list help you, you need to provide them
with an example that reproduces this behaviour.
Well, I cannot reproduce it myself in reliable manner, it happens at
random, but I will try to come up with something.
-vv -D will give you some debugging information.
Hmm, they are printing info to STDOUT and it interferes with the output
of the processing (small wish: could you add optional parameter, like
-vv=filename and/or -D=filename meaning the output would be directed to
a file?).
However, I spotted dead lock again -- one of the files was not
transferred to the remote computer, and parallel was stuck at such point
(transferring it).
Some interesting jobs on local computer:
27067 pts/6 S+ 0:00 sh -c true;
rsync -rlDzRE -essh ./XXXXXXX.YYY user@cosmos:.;ssh user@cosmos
PARALLEL_SEQ=$PARALLEL_SEQ\;export PARALLEL_SEQ\;PARALLEL_PID=$PAR
27068 pts/6 S+ 0:00 rsync -rlDzRE -essh ./XXXXXXX.YYY
user@cosmos:.
27069 pts/6 S+ 0:00 ssh -l user cosmos
rsync --server -lDErRze.iLs . .
And on remote computer:
14102 ? Ss 0:00 rsync --server -lDErRze.iLs . .
14179 ? S 0:00 rsync --server -lDErRze.iLs . .
Does it mean it is rsync fault?
Kind regards,