Re: [Monotone-devel] "mtn pull" hangs (was: "mtn clone" hangs)

[Ralf S. Engelschall]

On Tue, Nov 13, 2007, William Uther wrote:

> On 12/11/2007, at 7:19 PM, Ralf S. Engelschall wrote:
>
>>> It seems that the 'mtn pull' part is freezing. The first thing I would
>>> check is if the commands work individually. Can you execute these
>>> three commands:
>>>
>>> mtn db init --db=local.db
>>> mtn pull --db=local.db file:///v/freebsd/web/x/freebsd-snapshot.db
>>> FreeBSD.snapshot.src
>>> mtn co --db=local.db FreeBSD.snapshot.src y
>>
>> Ah, got it: "mtn pull" already hangs, too!
>>
>> | $ mtn db init --db=local.db
>> | $ mtn pull --db=local.db file:///v/freebsd/web/snapshot.db
>> FreeBSD.snapshot.src
>> | mtn: setting default branch include pattern to 'FreeBSD.snapshot.src'
>> | mtn: setting default branch exclude pattern to ''
>> | mtn: doing anonymous pull
>> | mtn: connecting to file:///v/freebsd/web/snapshot.db
>> | mtn: finding items to synchronize:
>> | [...no more outputs...]
>>
>> When repeating this under --debug the last lines of debug output are:
>>
>> | [...]
>> | mtn: noting key 'address@hidden' =
>> '8ad89008af9db804b7cc26045f9c0f4b1e059c7a' to send
>> | mtn: ticks: c="certificates"/256, k="keys"/1, r="revisions"/64
>> | mtn: ckr
>> | mtn: i/o probe with 0 armed
>> | mtn: wrote 3 bytes to fd -1 (peer stdio)
>> | mtn: i/o probe with 0 armed
>> | mtn: read 3 bytes from fd -1 (peer file:///v/freebsd/web/snapshot.db)
>> | mtn: processing 0 byte input buffer from peer 
>> file:///v/freebsd/web/snapshot.db
>> | mtn: queueing refinement query of epoch node '', level 0
>> | mtn: Beginning epoch refinement on client.
>> | mtn: wrote 31 bytes to fd -1 (peer file:///v/freebsd/web/snapshot.db)
>> | mtn: read 31 bytes from fd -1 (peer stdio)
>> | mtn: processing 0 byte input buffer from peer stdio
>> | mtn: processing refine cmd for epoch node at level 0
>> | mtn: queueing refinement response of epoch node '', level 0
>> | mtn: i/o probe with 0 armed
>> | mtn: wrote 51 bytes to fd -1 (peer stdio)
>> | mtn: i/o probe with 0 armed
>>
>>> My guess is that the second command will freeze in the same place as
>>> 'clone' did.
>>
>> Yes, exactly!
>>
>>> And then I'll ask if you're using Windows...
>>
>> <grin> No, definitely "NO.
>>
>>> file:// access
>>> to local repositories forks a sub-process to read the file, and that
>>> sometimes gets wedged on Windows.  If that is the case, then you've come
>>> across a 'known issue' which, as far as I know, noone is actively working
>>> on.  Try avoiding file:// URLs.
>
> I have no idea why the file:// URL would be failing (other than on
> Windows).  This is tested for in
> the unit test "netsync_over_pipes".  What platform are you running on?  Is
> the db you're pulling from local, or on some file server?

It is Monotone 0.37 under FreeBSD 6.2 and the database is on
the local UFS filesystem. If I pull from the same database via
ssh://localhost/<path> instead of file:<path> everything works just
fine. The problem seems to be really related to the "file" I/O.

                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com