Thread: [JSch-users] trying to set TERM=dumb on a terminal shell via ChannelShell interface
Status: Alpha
Brought to you by:
ymnk
From: Alan E. <ala...@gm...> - 2008-07-08 18:09:19
|
Hello everyone. I'm the author of the SshConsolePlugin for JEdit. I'm trying to do a channelShell.setEnv("TERM", "dumb"), so that I don't have to see all these funny vt100 characters in the console shell. It doesn't seem to work. I get this error whenever I try to set an environment variable. I get the following exception. Am I doing something wrong? I tried it first this way: // Hashtable env = new Hashtable(); // env.put("TERM", "dumb"); // channelShell.setEnv(env); And later I updated to the latest jsch and tried it this way. No difference channelShell.setEnv("TERM", "dumb"); 11:03:48 AM [AWT-EventQueue-0] [error] Connection: com.jcraft.jsch.JSchException: failed to send channel request 11:03:48 AM [AWT-EventQueue-0] [error] Connection: at com.jcraft.jsch.Request.write(Request.java:65) 11:03:48 AM [AWT-EventQueue-0] [error] Connection: at com.jcraft.jsch.RequestEnv.request(RequestEnv.java:52) 11:03:48 AM [AWT-EventQueue-0] [error] Connection: at com.jcraft.jsch.ChannelSession.sendRequests(ChannelSession.java:222) 11:03:48 AM [AWT-EventQueue-0] [error] Connection: at com.jcraft.jsch.ChannelShell.start(ChannelShell.java:44) 11:03:48 AM [AWT-EventQueue-0] [error] Connection: at com.jcraft.jsch.Channel.connect(Channel.java:200) |
From: <ym...@jc...> - 2008-07-09 00:25:43
|
Hi, +-From: "Alan Ezust" <ala...@gm...> -- |_Date: Tue, 8 Jul 2008 11:09:17 -0700 _______ | |Hello everyone. I'm the author of the SshConsolePlugin for JEdit. |I'm trying to do a channelShell.setEnv("TERM", "dumb"), so that I |don't have to see all these funny vt100 characters in the console |shell. |It doesn't seem to work. I get this error whenever I try to set an |environment variable. To enable 'setEnv', you need to add 'AcceptEnv TERM' to '/etc/ssh/sshd_config', if you are connecting to OpenSSH's sshd. To change terminal type without 'setEnv', you can invoke channelShell.setPtyType("dumb"); before connecting it. Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: Oberhuber, M. <Mar...@wi...> - 2008-07-11 15:15:34
|
Hi all, In JSch-0.1.37, Session.connect(int) sets isConnected=true in line 208, but the connectThread is only created later after Authentication is done. This leads to an NPE when Session.disconnect() is called from a different Thread, before the Authentication is finished: In line 1459, isConnected is already true, but in the synchronized(connectThread) statement the connectThread does not yet exist. I'm not sure how to best address this, but one option might be that disconnect() does this: if(connectThread==null) { //Not yet authenticated: Signal cancellation synchronized(this) { isConnected = false; } } and, the connect(int) method checks for isConnected still true at the right places during authentication. For another method addressing this in the client code (checking connect status in the MyUserInfo), see https://bugs.eclipse.org/bugs/show_bug.cgi?id=240420#c9 Thoughts? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: jsc...@li... > [mailto:jsc...@li...] On Behalf > Of Atsuhiko Yamanaka > Sent: Wednesday, July 09, 2008 2:25 AM > To: ala...@gm... > Cc: jsc...@li... > Subject: Re: [JSch-users] trying to set TERM=dumb on a > terminal shellvia ChannelShell interface > > Hi, > > +-From: "Alan Ezust" <ala...@gm...> -- > |_Date: Tue, 8 Jul 2008 11:09:17 -0700 _______ > | > |Hello everyone. I'm the author of the SshConsolePlugin for JEdit. > |I'm trying to do a channelShell.setEnv("TERM", "dumb"), so that I > |don't have to see all these funny vt100 characters in the console > |shell. > |It doesn't seem to work. I get this error whenever I try to set an > |environment variable. > > To enable 'setEnv', you need to add 'AcceptEnv TERM' to > '/etc/ssh/sshd_config', if you are connecting to OpenSSH's sshd. > > To change terminal type without 'setEnv', you can invoke > channelShell.setPtyType("dumb"); > before connecting it. > > Sincerely, > -- > Atsuhiko Yamanaka > JCraft,Inc. > 1-14-20 HONCHO AOBA-KU, > SENDAI, MIYAGI 980-0014 Japan. > Tel +81-22-723-2150 > +1-415-578-3454 > Fax +81-22-224-8773 > Skype callto://jcraft/ > > -------------------------------------------------------------- > ----------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > JSch-users mailing list > JSc...@li... > https://lists.sourceforge.net/lists/listinfo/jsch-users > |
From: <ym...@jc...> - 2008-07-14 07:13:32
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Fri, 11 Jul 2008 17:14:36 +0200 _______________________ | |In JSch-0.1.37, Session.connect(int) sets |isConnected=true in line 208, but the |connectThread is only created later after |Authentication is done. ... |I'm not sure how to best address this, but one |option might be that disconnect() does this: |if(connectThread==null) { | //Not yet authenticated: Signal cancellation | synchronized(this) { | isConnected = false; | } |} In that change, there is a possibility that 'connectThread' is assigned before entering synchronized clause. And then, 'this' (an instance of Session) has been already used to send data, so 'disconnect' may be blocked in some case. How about the following patch? --- jsch-0.1.39/src/com/jcraft/jsch/Session.java Thu Jun 12 07:06:49 2008 +++ jsch-0.1.40/src/com/jcraft/jsch/Session.java Mon Jul 14 05:05:36 2008 @@ -456,12 +456,21 @@ } isAuthed=true; - connectThread=new Thread(this); - connectThread.setName("Connect thread "+host+" session"); - if(daemon_thread){ - connectThread.setDaemon(daemon_thread); + + synchronized(Session.class){ + if(isConnected){ + connectThread=new Thread(this); + connectThread.setName("Connect thread "+host+" session"); + if(daemon_thread){ + connectThread.setDaemon(daemon_thread); + } + connectThread.start(); + } + else{ + // The session has been already down and + // we don't have to start new thread. + } } - connectThread.start(); } catch(Exception e) { in_kex=false; @@ -1487,10 +1496,12 @@ PortWatcher.delPort(this); ChannelForwardedTCPIP.delPort(this); - synchronized(connectThread){ - Thread.yield(); - connectThread.interrupt(); - connectThread=null; + synchronized(Session.class){ + if(connectThread!=null){ + Thread.yield(); + connectThread.interrupt(); + connectThread=null; + } } thread=null; try{ |
From: Oberhuber, M. <Mar...@wi...> - 2008-07-16 14:03:13
|
Hello Atsuhiko, yes this patch looks like a good solution that should fix the problem safely. But why do you synchronize on Session.class and not on this ? It seems that this would unnecessarily influence other Sessions that have absolutely nothing to do with this one. Also, synchronizing on this seems to have the added value that synchronized methods "setConfig" and "_write" can not run concurrently. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Atsuhiko Yamanaka [mailto:ym...@jc...] > Sent: Monday, July 14, 2008 9:13 AM > To: Oberhuber, Martin > Cc: jsc...@li... > Subject: Re: [JSch-users] JSch-0.1.37: NPE in > Session.disconnect() when calledbefore authenticated > > Hi, > > +-From: "Oberhuber, Martin" <Mar...@wi...> -- > |_Date: Fri, 11 Jul 2008 17:14:36 +0200 _______________________ > | > |In JSch-0.1.37, Session.connect(int) sets > |isConnected=true in line 208, but the > |connectThread is only created later after > |Authentication is done. > ... > |I'm not sure how to best address this, but one > |option might be that disconnect() does this: > |if(connectThread==null) { > | //Not yet authenticated: Signal cancellation > | synchronized(this) { > | isConnected = false; > | } > |} > > In that change, there is a possibility that > 'connectThread' is assigned before entering synchronized clause. > And then, 'this' (an instance of Session) has been already > used to send data, so 'disconnect' may be blocked in some case. > > How about the following patch? > > --- jsch-0.1.39/src/com/jcraft/jsch/Session.java Thu Jun > 12 07:06:49 2008 > +++ jsch-0.1.40/src/com/jcraft/jsch/Session.java Mon Jul > 14 05:05:36 2008 > @@ -456,12 +456,21 @@ > } > > isAuthed=true; > - connectThread=new Thread(this); > - connectThread.setName("Connect thread "+host+" session"); > - if(daemon_thread){ > - connectThread.setDaemon(daemon_thread); > + > + synchronized(Session.class){ > + if(isConnected){ > + connectThread=new Thread(this); > + connectThread.setName("Connect thread "+host+" session"); > + if(daemon_thread){ > + connectThread.setDaemon(daemon_thread); > + } > + connectThread.start(); > + } > + else{ > + // The session has been already down and > + // we don't have to start new thread. > + } > } > - connectThread.start(); > } > catch(Exception e) { > in_kex=false; > @@ -1487,10 +1496,12 @@ > PortWatcher.delPort(this); > ChannelForwardedTCPIP.delPort(this); > > - synchronized(connectThread){ > - Thread.yield(); > - connectThread.interrupt(); > - connectThread=null; > + synchronized(Session.class){ > + if(connectThread!=null){ > + Thread.yield(); > + connectThread.interrupt(); > + connectThread=null; > + } > } > thread=null; > try{ > |
From: <ym...@jc...> - 2008-07-17 00:59:37
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Wed, 16 Jul 2008 16:02:20 +0200 _______________________ | |Also, synchronizing on this seems to have the added value |that synchronized methods "setConfig" and "_write" can |not run concurrently. I'm sorry, but I could not understand above sentence. Do you mean that nobody gets a lock for an instance of "Foo" class if somebody has already gotten a lock for "Foo.class" object? Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: Oberhuber, M. <Mar...@wi...> - 2008-07-17 12:57:55
|
Hi, my point was that if the connection was in the process of being disconnected, running a setConfig() or _write() at the same time doesn't make much sense and is at risk of producing incorrect data. Therefore, if there is already a lock protecting _write() and setConfig(), it can make sense to re-use the same lock also for disconnect -- just to ensure that disconnect cannot happen at the same time as _write() or setConfig(). I don't think that this is a big issue, though, since the data produced by write or setConfig is doomed anyways when the connection is going down so if there are any inconsistencies those would normally not show up. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Atsuhiko Yamanaka [mailto:ym...@jc...] > Sent: Thursday, July 17, 2008 2:59 AM > To: Oberhuber, Martin > Cc: jsc...@li... > Subject: Re: [JSch-users] JSch-0.1.37: NPE in > Session.disconnect() whencalledbefore authenticated > > Hi, > > +-From: "Oberhuber, Martin" <Mar...@wi...> -- > |_Date: Wed, 16 Jul 2008 16:02:20 +0200 _______________________ > | > |Also, synchronizing on this seems to have the added value > |that synchronized methods "setConfig" and "_write" can > |not run concurrently. > > I'm sorry, but I could not understand above sentence. > Do you mean that nobody gets a lock for an instance of "Foo" class > if somebody has already gotten a lock for "Foo.class" object? > > > Sincerely, > -- > Atsuhiko Yamanaka > JCraft,Inc. > 1-14-20 HONCHO AOBA-KU, > SENDAI, MIYAGI 980-0014 Japan. > Tel +81-22-723-2150 > +1-415-578-3454 > Fax +81-22-224-8773 > Skype callto://jcraft/ > |
From: Oberhuber, M. <Mar...@wi...> - 2008-07-16 14:06:30
|
PS One drawback of synchronizing on either "this" or on Session.class is, that these objects are publicly available to clients. So, a malicious client who also synchronizes on the Session object or Session class at a wrong time might find an incorrect ordering of locks which might lead to deadlock eventually (which would not be the fault of JSch since the code inside your synchronized blocks is guaranteed to complete without external interaction; it would be the client's fault, but it would influence JSch). As a rule of thumb, I've been told that it is usually better to synchronize on local private Objects, which the clients can not access. So, instead of synchronizing on Session.class, I think you should synchronize on any local Object of your choice. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Oberhuber, Martin > Sent: Wednesday, July 16, 2008 4:02 PM > To: 'Atsuhiko Yamanaka' > Cc: jsc...@li... > Subject: RE: [JSch-users] JSch-0.1.37: NPE in > Session.disconnect() when calledbefore authenticated > > Hello Atsuhiko, > > yes this patch looks like a good solution that should > fix the problem safely. > > But why do you synchronize on Session.class and not on > this ? It seems that this would unnecessarily influence > other Sessions that have absolutely nothing to do with > this one. > > Also, synchronizing on this seems to have the added value > that synchronized methods "setConfig" and "_write" can > not run concurrently. > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > > -----Original Message----- > > From: Atsuhiko Yamanaka [mailto:ym...@jc...] > > Sent: Monday, July 14, 2008 9:13 AM > > To: Oberhuber, Martin > > Cc: jsc...@li... > > Subject: Re: [JSch-users] JSch-0.1.37: NPE in > > Session.disconnect() when calledbefore authenticated > > > > Hi, > > > > +-From: "Oberhuber, Martin" <Mar...@wi...> -- > > |_Date: Fri, 11 Jul 2008 17:14:36 +0200 _______________________ > > | > > |In JSch-0.1.37, Session.connect(int) sets > > |isConnected=true in line 208, but the > > |connectThread is only created later after > > |Authentication is done. > > ... > > |I'm not sure how to best address this, but one > > |option might be that disconnect() does this: > > |if(connectThread==null) { > > | //Not yet authenticated: Signal cancellation > > | synchronized(this) { > > | isConnected = false; > > | } > > |} > > > > In that change, there is a possibility that > > 'connectThread' is assigned before entering synchronized clause. > > And then, 'this' (an instance of Session) has been already > > used to send data, so 'disconnect' may be blocked in some case. > > > > How about the following patch? > > > > --- jsch-0.1.39/src/com/jcraft/jsch/Session.java Thu Jun > > 12 07:06:49 2008 > > +++ jsch-0.1.40/src/com/jcraft/jsch/Session.java Mon Jul > > 14 05:05:36 2008 > > @@ -456,12 +456,21 @@ > > } > > > > isAuthed=true; > > - connectThread=new Thread(this); > > - connectThread.setName("Connect thread "+host+" session"); > > - if(daemon_thread){ > > - connectThread.setDaemon(daemon_thread); > > + > > + synchronized(Session.class){ > > + if(isConnected){ > > + connectThread=new Thread(this); > > + connectThread.setName("Connect thread "+host+" session"); > > + if(daemon_thread){ > > + connectThread.setDaemon(daemon_thread); > > + } > > + connectThread.start(); > > + } > > + else{ > > + // The session has been already down and > > + // we don't have to start new thread. > > + } > > } > > - connectThread.start(); > > } > > catch(Exception e) { > > in_kex=false; > > @@ -1487,10 +1496,12 @@ > > PortWatcher.delPort(this); > > ChannelForwardedTCPIP.delPort(this); > > > > - synchronized(connectThread){ > > - Thread.yield(); > > - connectThread.interrupt(); > > - connectThread=null; > > + synchronized(Session.class){ > > + if(connectThread!=null){ > > + Thread.yield(); > > + connectThread.interrupt(); > > + connectThread=null; > > + } > > } > > thread=null; > > try{ > > |
From: <ym...@jc...> - 2008-07-17 01:06:19
|
Hi, +-From: "Oberhuber, Martin" <Mar...@wi...> -- |_Date: Wed, 16 Jul 2008 16:05:38 +0200 _______________________ | |As a rule of thumb, I've been told that it is usually |better to synchronize on local private Objects, which |the clients can not access. So, instead of synchronizing |on Session.class, I think you should synchronize on |any local Object of your choice. You are right. At first, I had thought to allocate an object for that synchronization, but I had hesitated to waist the resource and decided to re-use the existing one; Session.class OK, I agree with you. We should not use such a public object for the synchronization. I'll use private and local object. Thank for your suggestions. Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: <gle...@jp...> - 2008-09-08 20:32:48
|
We have begun a migration to a new build server and I have been having a problem with the ssh-exec task failing with the following message "Remote command failed with exit status -1" I attempted to test this using the Exec.java example program and recieved the same results (the message was "exit status: -1") The odd thing is that this works fine from our old build box and it works fine from the new build box to other hosts than this one specific one (which happens to be our QA box). I thought that upgrading to ant 1.7.1 (from 1.7.0) might help. no use. This appears to fail with any command I try to run, even echo commands. Here is the sytem info: Old Build Box: OS: Windows Server 2003 Service Pack 1 JDK: 1.4.2_03 New Build Box OS: Windows Server 2003 Service Pack 2 JDK: 1.4.2_17 Target host: OS: Solaris SSH Version: Sun_SSH_1.1 Thanks, Glenn Brown. Generally, this communication is for informational purposes only and it is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. In the event you are receiving the offering materials attached below related to your interest in hedge funds or private equity, this communication may be intended as an offer or solicitation for the purchase or sale of such fund(s). All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities. |
From: <ym...@jc...> - 2008-09-09 01:01:06
|
Hi, +-From: gle...@jp... ------ |_Date: Mon, 8 Sep 2008 15:30:48 -0500 __ | |We have begun a migration to a new build server and I have been having a |problem with the ssh-exec task failing with the following message "Remote |command failed with exit status -1" ... |I thought that upgrading to ant 1.7.1 (from 1.7.0) might help. no use. I guess that is a reported bug[1] and has been fixed Apache Ant 1.7.1. If you need to stick to Apache Ant 1.7.0, please refer to a patch[2] for it. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43092 [2] http://www.mail-archive.com/us...@an.../msg29845.html Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ |
From: <gle...@jp...> - 2008-09-09 16:31:15
|
Thats just it, I upgraded to 1.7.1 and still no dice. ym...@jc... (Atsuhiko Yamanaka) Sent by: jsc...@li... 09/08/2008 08:00 PM To gle...@jp... cc jsc...@li... Subject Re: [JSch-users] sshexec yeilds return code of -1 when executing from some hosts but not others. Hi, +-From: gle...@jp... ------ |_Date: Mon, 8 Sep 2008 15:30:48 -0500 __ | |We have begun a migration to a new build server and I have been having a |problem with the ssh-exec task failing with the following message "Remote |command failed with exit status -1" ... |I thought that upgrading to ant 1.7.1 (from 1.7.0) might help. no use. I guess that is a reported bug[1] and has been fixed Apache Ant 1.7.1. If you need to stick to Apache Ant 1.7.0, please refer to a patch[2] for it. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43092 [2] http://www.mail-archive.com/us...@an.../msg29845.html Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ JSch-users mailing list JSc...@li... https://lists.sourceforge.net/lists/listinfo/jsch-users Generally, this communication is for informational purposes only and it is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. In the event you are receiving the offering materials attached below related to your interest in hedge funds or private equity, this communication may be intended as an offer or solicitation for the purchase or sale of such fund(s). All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities. |