remote:/home/me/ $ uname -a
FreeBSD remote.example.com 7.3-RELEASE-p2 FreeBSD 7.3-RELEASE-p2 #0 r210461M: Sun Jul 25 11:12:37 UTC 2010
remote:/home/me/ $ which fossil
/home/me/bin/fossil
remote:/home/me/ $ fossil new test-repo.fossil
project-id: ...
server-id: ...
admin-user: ...

I then attempt to clone this repository.

local:/home/me/ $ uname -a
Linux local 2.6.35-19-generic #28-Ubuntu SMP Sun Aug 29 06:34:38 UTC 2010 x86_64 GNU/Linux
local:/home/me/ $ fossil clone ssh://username@remote.example.com//home/me/test-repo.fossil?fossil=/home/me/bin/fossil test-repo.fossil
me@remote.example.com's password: 
                Bytes      Cards  Artifacts     Deltas
Send:              49          1          0          0

Output then stops there, with the process not accepting any input or responding, until killed with ^C.

I imagine there must be some issue with FreeBSD's SSH.

drh added on 2010-09-06 23:23:41:
Can you ssh once from the linux box into the freebsd box? Perhaps ssh is asking you to accept a certificate, and that question is getting mixed in with the Fossil traffic and confusing things.

anonymous added on 2010-09-07 00:31:59:
I had to SSH into the box to build fossil and create the repo. It works fine for that.

anonymous added on 2010-09-20 00:07:47:
I have the same issue trying to clone from an OpenBSD server. Just hangs. Normal ssh works fine so does git and hg ssh cloning.

ron added on 2010-10-17 07:04:40:
I'm having the exact same problem -- "fossil clone ssh://..." used to work, but no longer does.

The regular fossil clone ssh://name@server/path localname just hangs forever.

The slightly more obscure fossil clone ssh://name@server:port/path localname gives a "fossil: ssh connection failed" error.

Obviously, I have no problem connecting using ssh to either server, and they are running different Linux distros -- so it's not specific to a particular distro.

anonymous claiming to be Joerg Sonnenberger added on 2010-12-24 23:55:38:
I think I found the root of this problem. fossil is using ssh -T to connect to the server. This inhibits the creation of a pty and therefore sh is started with a pipe for stdin/stdout/stderr. This in turn makes libc use buffering. The commands are sent to this shell and the following POST request is obtained by sh too (due to the buffering). As a result, the remote fossil is waiting in read for data that will never arrive.

I think the best approach for this is to not do fancy things involving the shell, but switch to something like:

ssh -e none -T <host> <fossil> ssh-sync <repo-path>

ssh-sync differs from test-http by looping on stdin until it is closed. E.g. use ssh like the equivalent of keep-alive with HTTP.

Advantage: much less chance for a shell to mock things up. It can be easily changed to make fossil an ssh subsystem, which might be a nice option for deployment on central servers, where normal users shouldn't have shell access.

anonymous claiming to be viric added on 2011-01-26 22:09:28 UTC:
I also get a fossil blocked in that situation.

If I turn --httptrace on, I can later run this:

$ ssh -e none -T vicerveza "fossil test-http fossil/encara.fossil" < http-request-1.txt 

which works perfectly without hanging and getting all the HTTP answer. But "fossil sync --httptrace" hangs, with the http reply file void.

Who do you think is buffering (about libc)? Fossil? As it closes its stdout, buffers will be flushed. Do you think opensshd does the buffering? Why would it?

This happens to me in the version [6f42e76d80] 2011-01-13.

anonymous claiming to be viric added on 2011-01-26 22:10:56 UTC:
Just as extra information... I have other repositories in that computer where I can sync and clone fine through ssh (some other 'repository.fossil' files next to the one that blocks on sync).

mjanssen added on 2011-02-02 01:02:18 UTC:
Could you check if the changes described in ticket [884c40589fcee6fa54d18eb3e8db1d1ba337a294] resolve the problem?

anonymous claiming to be viric added on 2011-02-07 23:49:23 UTC:
I think it is not related.

Of course, fossil should be using an ssh remote command execution within a non-interactive shell, a non-login shell. That should make the remote interpreter to avoid anything like the MOTD, or any welcome message the user could have set.

As fossil is not running ssh in such a way, welcome messages to the shell annoy. I could not find how to call ssh without parameters, without specifying any program to run. On the other hand, running "ssh REMOTE sh" (run the program sh) would make the shell non-login, so no displaying any welcome message. It could be used to overcome this login problem.

But the problem I seconded above was not related to any welcome message. Some repositories sync, some hang, between the very same computers.

viriketo added on 2011-02-16 20:42:19 UTC:
The problem went away for my use case after [7c8519003d].

I think the key was in transport_load_buffer(..., 1000), that was waiting for either 1000 bytes or EOF. As with ssh EOF does not come, and data transmitted may be below 1000 bytes, we need a different approach.

With the ssh case, the call goes transport_load_buffer(..., 2), asking for two bytes or EOF.

I'm not sure if it works in all cases.

Closing as part of periodic cleanup.