AW: [JSch-users] SOLVED: SCP will not exit, "session down" error, SSH_MSG_DISCONNECT: 2 Received ieof for nonexistent channel 0

[Manuel B. <man...@gm...>]

Hi Thomas

Are will still talking about the ScpTo example with all GUI code =
removed?

The ScpTo example is missing "session.disconnet();" at the end.

Inferior alternatives are:

- Don't remove "System.exit(0);" (I guess you have removed it; the =
original
example requires it due to Swing).

- Add "System.gc();" at the end; then the garbage collector will call
Session.finalize(), which in turn class disconnect(). Might not work on =
all
platforms.

"session.disconnect()" is the best solution, of course.

-- Manuel

-----Urspr=FCngliche Nachricht-----
Von: Thomas [mailto:pha...@ya...]=20
Gesendet: Montag, 20. Juni 2005 20:12
An: Manuel Bleichenbacher
Betreff: Re: [JSch-users] SOLVED: SCP will not exit, "session down" =
error,
SSH_MSG_DISCONNECT: 2 Received ieof for nonexistent channel 0

I implemented the changes you listed below, but ScpTo still hangs at the =
end
of main() for me. I'm working on Fedora Core 2 if that matters.


--- Manuel Bleichenbacher <man...@gm...> wrote:

> Hi
>=20
> I've encountered many problems when using SCP (copy from and to remote =

> site, creating directories). Sometimes the program would hang after it =

> had finished copying, sometimes I got a "session down" exception,=20
> sometimes it just worked fine.
>=20
> As the root of the problems I have identified the following issues:
>=20
> Channel.eof() sent an EOF message even if the channel had already been =

> closed. This in turn resulted in an error from the remote site, which=20
> caused an exception:
>=20
>   com.jcraft.jsch.JSchException: SSH_MSG_DISCONNECT: 2 Received ieof=20
> for nonexistent channel 0.
>=20
> The exception was quietly eaten without any error handling.
>=20
> Additionally, I have removed all two calls of System.gc() because this =

> is simply not acceptable for many applications, in particular not for=20
> a J2EE application.
>=20
> Thus, I've made the following modifications to Channel.java and=20
> Session.java (against jsch-0.1.20):
>=20
>=20
> Channel.java:
>=20
> 231d230
> <     if (!close) {
> 243d241
> <     }
>=20
>=20
> Session.java:
>=20
> 212c212
> < 	      //System.gc();
> ---
> > 	      System.gc();
> 942d941
> <     Exception exception =3D null;
> 1192,1193d1190
> <       if (socket =3D=3D null || !socket.isClosed())
> <     	exception =3D e;
> 1209,1210d1205
> <     if (exception !=3D null)
> <     	throw new RuntimeException(exception);
> 1268c1263
> <     // System.gc();
> ---
> >     System.gc();
>=20
>=20
> This is a rather simple fix. I think it might be even better to remove =

> most of the calls of Channel.eof(). I don't think they're necessary=20
> after every read failure.
>=20
> Session.run() will now throw an exception if something goes wrong. In=20
> many cases, this should help uncover the real cause of a problem.
>=20
> I hope these modifications can be incorporated into the next release=20
> of Jsch.
>=20
> Regards
> Manuel
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies =

> from IBM. Find simple to follow Roadmaps, straightforward articles,=20
> informative Webcasts and more! Get everything you need to get up to=20
> speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> JSch-users mailing list
> JSc...@li...
> https://lists.sourceforge.net/lists/listinfo/jsch-users
>=20


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com=20