parallel
[Top][All Lists]
Advanced

[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,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]