bug-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problem with cfagent on Mac OS X 10.4


From: Orion Poplawski
Subject: Problem with cfagent on Mac OS X 10.4
Date: Tue, 25 Oct 2005 14:39:31 -0600
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm experiencing an odd problem with cfengine on Mac OS X 10.4.  I'm
using a snapshot from today (10/25/05).

Basically, the first connection to the server is not completely torn
down before the second connection it made.  This causes the server to
abort the second connection with:

Oct 25 12:03:27 earth cfservd[2643]:  Denying repeated connection from
::ffff:192.168.0.77

The client gets the following:

*********************************************************************
 Main Tree Sched: copy pass 1 @ Tue Oct 25 14:24:14 2005
*********************************************************************

Checking copy from localhost:/usr/local/bin/rsync_hfs to
/usr/local/bin/rsync
cfengine:raffles: Can't stat /usr/local/bin/rsync_hfs in copy
Checking copy from earth:/etc/cfengine/files/raffles to /
Connect to earth = 192.168.0.8, port =5308
Found address (192.168.0.8) for host earth
Updating last-seen time for earth
Loaded /var/cfengine/ppkeys/root-192.168.0.8.pub
cfengine:raffles: Received signal 13 (SIGPIPE) while doing [no_active_lock]
cfengine:raffles: Logical start time Tue Oct 25 14:24:14 2005
cfengine:raffles: This sub-task started really at Tue Oct 25 14:24:14 2005


Here is a packet trace of the transition.  Notice that the final ack
from raffles (the mac client) arrives after the start of the second
connection (from port 52233), and about 1/2 second after the FIN from earth.

12:27:57.559160 IP earth.cora.nwra.com.cfengine >
raffles.cora.nwra.com.52232: P 1232:1243(11) ack 1805 win 2252
<nop,nop,timestamp 494973418 1350677013>
12:27:57.559911 IP raffles.cora.nwra.com.52232 >
earth.cora.nwra.com.cfengine: P 1805:1872(67) ack 1243 win 65535
<nop,nop,timestamp 1350677013 494973418>
12:27:57.560150 IP earth.cora.nwra.com.cfengine >
raffles.cora.nwra.com.52232: P 1243:1260(17) ack 1872 win 2252
<nop,nop,timestamp 494973418 1350677013>
12:27:57.563407 IP raffles.cora.nwra.com.52232 >
earth.cora.nwra.com.cfengine: F 1872:1872(0) ack 1260 win 65535
<nop,nop,timestamp 1350677013 494973418>
12:27:57.563471 IP earth.cora.nwra.com.cfengine >
raffles.cora.nwra.com.52232: F 1260:1260(0) ack 1873 win 2252
<nop,nop,timestamp 494973419 1350677013>
12:27:57.629999 IP raffles.cora.nwra.com.52233 >
earth.cora.nwra.com.cfengine: S 4260444511:4260444511(0) win 65535 <mss
1460,nop,wscale 0,nop,nop,timestamp 1350677013 0>
12:27:57.630030 IP earth.cora.nwra.com.cfengine >
raffles.cora.nwra.com.52233: S 352953635:352953635(0) ack 4260444512 win
5792 <mss 1460,nop,nop,timestamp 494973436 1350677013,nop,wscale 2>
12:27:57.630244 IP raffles.cora.nwra.com.52233 >
earth.cora.nwra.com.cfengine: . ack 1 win 65535 <nop,nop,timestamp
1350677013 494973436>
12:27:57.630538 IP earth.cora.nwra.com.cfengine >
raffles.cora.nwra.com.52233: F 1:1(0) ack 1 win 1448 <nop,nop,timestamp
494973436 1350677013>
12:27:57.630749 IP raffles.cora.nwra.com.52233 >
earth.cora.nwra.com.cfengine: . ack 2 win 65535 <nop,nop,timestamp
1350677013 494973436>
12:27:57.632616 IP raffles.cora.nwra.com.52233 >
earth.cora.nwra.com.cfengine: P 1:56(55) ack 2 win 65535
<nop,nop,timestamp 1350677013 494973436>
12:27:57.632634 IP earth.cora.nwra.com.cfengine >
raffles.cora.nwra.com.52233: R 352953637:352953637(0) win 0
12:27:58.001615 IP earth.cora.nwra.com.cfengine >
raffles.cora.nwra.com.52232: F 1260:1260(0) ack 1873 win 2252
<nop,nop,timestamp 494973529 1350677013>
12:27:58.001885 IP raffles.cora.nwra.com.52232 >
earth.cora.nwra.com.cfengine: . ack 1261 win 65535 <nop,nop,timestamp
1350677014 494973529>

I don't see this with my 10.3 clients.  Haven't tested with other 10.4
clients.  Thought maybe it have something to do with delayed acks, but
setting net.inet.tcp.delayed_ack=0 does not affect it.  At this point I
can only think of using a sleep(1) between connections to work around.

- - Orion Poplawski

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDXpgCORnzrtFC2/sRAgL8AKDqGJeH4vw6Ob9TRp09eF/YUCPYbgCePSBj
CNtAy693DpS7VtGx2VnZugI=
=dHpG
-----END PGP SIGNATURE-----





reply via email to

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