On 07/23/2011 07:36 AM, Johannes Fichtinger wrote:
Hi Victor
Am Samstag, 23. Juli 2011 schrieb Victor Munoz:
Today, I lost the ability to synchronize between two machines, one had
lenny until today morning, and the other was sid. I was using
apt-pinning to keep both unison versions compatible.
Yesterday night I was able to sync both machines for the last time.
Then, today morning, I was not. It connects to the server, it
recognizes the changes, and it offers me all the changes for approval.
Then, when it has to start copying, it just waits for ever, and no
progress is done.
From yesterday morning on I see exactly the same problem on my machine. I am
running latest SID here. On another machine with SID updated the last time one
week ago running unison 2.32.52-3+b1 unison works perfectly.
Johannes
Hmmm. I'm going to add what will probably just be noise, but thought my
situation just might be worth mentioning.
I run Debian testing on four workstations. I use aptitude to upgrade all
of them every day around 11:00-12:00 UTC. I also use unison-gtk to
synchronize data among them.
Yesterday following the updates I temporarily lost ability to
synchronize two of these systems using unison-gtk 2.32.52-3+.
Here's where the water gets much muddier.
I rebooted the two troublesome systems. That was no help at all. In
fact, I lost my ability to connect to the network with both of those
systems. The tray icon (I use wicd.) and ifconfig indicated that I had a
connected state with the correct IPs, but I couldn't hit my gateway with
either of these two systems.
I had the two of these systems which travel amongst various networks set
to use ICMP filtering (including ping and pong). Guess which ones were
having trouble.
I changed the ICMP filtering to allow ping and pong, and everything
started working -- the network connection and unison-gtk.
In reviewing /var/log/aptitude I notice that the only dependency of
unison-gtk that was upgraded in the past couple of days was libc6
(2.13-7 -> 2.13-10), and that was during yesterday's upgrade session --
just before the trouble started.
I have not bothered to re-instate ICMP filtering to its previous state
of refusing ping and pong because -- a) I'm lazy, and b) its paranoid
and silly and probably not good network etiquette for a network I've
been given permission to visit. (I'm a consultant there.)
What I'm reporting here is obviously not an exact match to the
situations you (Victor and Johannes) are reporting. Victor specifically
said he's not using any iptables rules, and I'm assuming Johannes would
have mentioned any significant variation from that. Victor saw some more
general network misbehavior, but Johannes didn't report any such issue.
Of course, we're all using different versions of Debian.
I'm only sending this because I found the confluence of similar
behaviors on three (four?) different versions of Debian at exactly the
same time period to be interesting. I thought there might be a
peripheral -- if not a central -- connection here.
Best regards,
Gilbert
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e2ac834.6090...@comcast.net