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