UNISON не работает синхронизация

Тоже, только с опцией -debug all

gudik@sa-pc128:~/.unison$ unison /data/tmp/test/ ssh://aleksey@1.2.3.4//data/tmp/test/ -debug all
[startup] Preferences:
ui = graphic
host = 
server = false
prefsdocs = false
doc = 
version = false
silent = false
dumbtty = false
testserver = false
rest = ssh://aleksey@1.2.3.4//data/tmp/test/
rest = /data/tmp/test/
showprev = false
selftest = false
confirmmerge = false
retry = 0
repeat = 
contactquietly = false
key = 
label = 
expert = false
height = 15
auto = false
maxthreads = 0
prefer = 
force = 
sortnewfirst = false
sortbysize = false
keeptempfilesaftermerge = false
diff = diff -u CURRENT2 CURRENT1
backupdir = 
maxbackups = 2
backups = false
backupsuffix = 
backupprefix = .bak.$VERSION.
backuploc = central
copymax = 1
copyquoterem = default
copythreshold = -1
copyprogrest = rsync --partial --append-verify --compress
copyprog = rsync --partial --inplace --compress
rsync = true
fastcheck = default
ignorelocks = false
dumparchives = false
ignorearchives = false
showarchive = false
rootsName = 
fat = false
allHostsAreRunningWindows = false
someHostIsRunningWindows = false
confirmbigdel = true
batch = false
root = ssh://aleksey@1.2.3.4//data/tmp/test/
root = /data/tmp/test/
killserver = false
halfduplex = false
stream = true
addversionno = false
servercmd = 
sshargs = 
rshargs = 
rshcmd = rsh
sshcmd = ssh
xferbycopying = true
sshversion = 
ignoreinodenumbers = false
links-aux = true
links = default
times = false
group = false
owner = false
numericids = false
dontchmod = false
perms = 1023
rsrc-aux = false
rsrc = default
maxerrors = 1
unicodeCS = false
unicodeEnc = false
unicode = default
someHostIsInsensitive = false
ignorecase = default
timers = false
terse = false
logfile = /home/gudik/unison.log
log = true
debugtimes = false
debug = all
addprefsto = 
Contacting server...
[remote] Shell connection: ssh (ssh, -l, aleksey, 1.2.3.4, -e, none, unison, -server)
aleksey@1.2.3.4's password: 
[globals] Checking path '' for expansions
Connected [//bomond//data/tmp/test -> //sa-pc128//data/tmp/test]
[startup] Roots: 
        /data/tmp/test/
        ssh://aleksey@1.2.3.4//data/tmp/test/
  i.e. 
        /data/tmp/test/
        ssh://aleksey@1.2.3.4//data/tmp/test/
  i.e. (in canonical order)
       /data/tmp/test
       //bomond//data/tmp/test

[props] Setting permission mask to 1777 (1777 and 7777)

up

Разобрался: http://www.snailbook.com/faq/mtu-mismatch.auto.html

=============

Short Answer You probably have an MTU/fragmentation problem. For each network interface on both client and server set the MTU to 576, eg ifconfig eth0 mtu 576. If the problem goes away, read on. Long Answer Long answer: At each routing hop, IP packets bigger than the outgoing interface's Maximum Transmission Unit (MTU) get fragmented. Only the first fragment has TCP port numbers. Firewalls often behave badly in the presence of packet fragmentation, dropping everything but the first fragment since the subsequent ones can't be matched against the firewall rules. Some NAT configuration (eg many-to-one NAT or port address translation) can't match the fragments against their translation state tables.

Arguably, such devices should perform packet reassembly first so as to properly consider fragmented packets. However, this is more complicated and so is often not done. Also, this feature would raise a possible starvation attack against the packet filter, by sending many bogus initial fragments and causing the device to store them for reassembly with subsequent packets which will never come.

Logging in and using the shell will normally generate relatively small packets, and so the initial connection proceeds normally ; however if do you something that generates a lot of data (eg cat'ing a big file or starting an X Windows application), you may generate a packet bigger than the MTU.

Let's say it's a 1500 byte IP packet and the router has 2 different MTU's (say 1500 & 1484) and no firewall. When the router goes to forward it, the packet is too big for the interface MTU (1484), so the router breaks it into 2 fragments, 0 and 1. Fragment 0 contains the first 1484 bytes (including the TCP source and dest ports) and fragment 1 contains the remaining 16 bytes. Both fragments are sent on to their destinations.

When the first fragment reaches its target, it's held by the IP stack until the remaining fragments arrive, at which time the IP packet is reassembled and passed up the stack to TCP. If all fragments are not received by the timeout, the entire IP packet is discarded and an ICMP «timeout during reassembly» error is sent back.

Now add your firewall, which drops fragment 1. Your 1500 byte IP packet times out during reassembly and TCP retries, by sending another 1500 byte packet. Repeat. Eventually, TCP will time out and you'll get a connection termination.

IP stack parameters (such as Path MTU Discovery) and external variables (such as the MTU's of all the hops between hosts) can also affect whether or not a given connection will have this problem.