| Summary: | LocalCommand is executed to early | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | fs-linux_bug | ||||
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> | ||||
| Status: | CLOSED FIXED | ||||||
| Severity: | normal | CC: | djm | ||||
| Priority: | P2 | ||||||
| Version: | 5.1p1 | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 1626 | ||||||
| Attachments: |
|
||||||
|
Description
fs-linux_bug
2009-06-15 05:13:35 AEST
Created attachment 1698 [details]
Delay execution of localcommand a tiny bit
Could you please try this patch?
The patch doesn't help, it only changes the problem. One did not get the "Enter passphrase"-loop now, with this patch unison executes ssh, but this ssh-client, which uses the master, seems not able to use the connection and just hangs (I didn't test how whether there's some kind of timeout if I wait _long_ enough, I killed ssh after 7 minutes) Could you enable debugging on both the master and slave ssh commands and attach the output? Send via email from email discussion: the reporter was running an interactive program that expected to have access to the up SSH connection. This is outside the intended usage of LocalCommand, which was provided to allow one-off initialisation of tunnels, etc. In particular, ssh(1) execution is blocked while the LocalCommand is executing, so there is no access to the SSH connection possible. I have updated the manpage to explain the constraints better, but the constraints themselves will not be changing. With the release of 5.4p1, this bug is now considered closed. |