I upgraded to lsh-2.0 today, and now lsftp doesn't work :-/ Is it just me? I've tried it against all manner of servers and it always fails...
# lsftp <hostname> -- 'cd /tmp' Broken pipe
Actually, the same thing happens even if I make up some bogus value for the hostname so it doesn't appear to be a compatibility issue.
Trying to get more details...
# lsftp -v <hostname> -- 'cd /tmp' lshg: No usable gateway found, launching lsh instead. Broken pipe
... and...
# lsftp -V <hostname> -- 'cd /tmp' Child died! Exited with status 0 Broken pipe
This is a sparc running Solaris 9. lsh and lshd work fine.
If there's any simple way for me to gather more useful information please let me know. I've tried tracing the process to see if there's some problem with access to a file or something but have not been able to turn up anything useful. Not having a real clear understanding of how lsftp is supposed to work and what other programs might be involved I'm not sure where to go from here with troubleshooting.
Hi there,
I upgraded to lsh-2.0 today, and now lsftp doesn't work :-/ Is it just me? I've tried it against all manner of servers and it always fails...
# lsftp <hostname> -- 'cd /tmp' Broken pipe
Actually, the same thing happens even if I make up some bogus value for the hostname so it doesn't appear to be a compatibility issue.
lsftp typically runs lshg -G <whatever you send to lsftp before --> to set up a connection, so you might want to try to see if that works. You might also try pre-establishing a gateway (with lsh -G -N -B hostname or something like that) or using another program for transport (setting LSFTP_RSH to your lsh).
I think the problem you describe could occur if there's no gateway available and lshg doesn't find you lsh to fall back on (lsh not in PATH).
HTH /Pontus
Thanks for your reply Pontus.
lsftp typically runs lshg -G <whatever you send to lsftp before --> to set up a connection, so you might want to try to see if that works. You might also try pre-establishing a gateway (with lsh -G -N -B hostname or something like that) or using another program for transport (setting LSFTP_RSH to your lsh).
I think the problem you describe could occur if there's no gateway available and lshg doesn't find you lsh to fall back on (lsh not in PATH).
This did help me to further isolate the problem. When I set LSFTP_RSH to lsh (thus avoiding lshg) all is well. So I tried running lshg -G from the command line - tracing the process shows that it checks for the existance of a gateway and on failing to find one it execs lsh. All seems to go fine for a while - things continue as for a regular lsh session - on the server I even see successful auth logged by lshd. But in the end, I see this...
Assertion failed: NULL == sys->files[fd][ev].f && "multiple handlers registered for a file event", file sys.c, line 109
And then I get a core file from lsh :-/ I see that sys.c is a part of liboop - I am using version 1.0. Line 109 is a part of the sys_on_fd function.
I can work around this issue now, so thanks for pointing me in the right direction. Perhaps my observations will be helpful to you and Niels. If there are any other tests I can run that would help you to understand what is happening please let me know.
It's still possible that this is unique to my install, but I have spent much of the day building and rebuilding with all different types of options - is there anyone else on the list using lsh-2.0 on Solaris 9?
Pete Naylor pete@geckoworks.com writes:
Assertion failed: NULL == sys->files[fd][ev].f && "multiple handlers registered for a file event", file sys.c, line 109
It would help to know which fd it's trying to install multiple event handlers for. If you examine the process or the core file in a debugger, the first thing to do is to back up to a frame where you have the corresponding lsh_fd object, and display the contents of that object.
My guess is that it's a genuine bug in lsh, not a bug in liboop. (Only Solaris-related problems with liboop that I have seen have been for the ancient Solaris-2.4, where liboop goes into an infinite signal handler loop. If anybody is still running that, I have a patched liboop-1.0 at http://www.lysator.liu.se/~nisse/misc).
Can you list precisely which steps are needed to reproduce the bug? It would be good to add that to the lsh testsuite.
Thanks for your help, /Niels
-
nisse＠lysator.liu.se -
Pete Naylor -
Pontus Freyhult