From jdsw2002 at yahoo.com Fri May 4 02:49:04 2007 From: jdsw2002 at yahoo.com (jd) Date: Fri, 4 May 2007 02:49:04 -0700 (PDT) Subject: [paramiko] pid of command executed on remote machine. Message-ID: <907974.8545.qm@web35813.mail.mud.yahoo.com> Hi everyone I would like to start the process on a remote node is background, get its pid. How does one do that ? I am using chan.exec_command /Jd --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.lag.net/pipermail/paramiko/attachments/20070504/625d46f2/attachment.htm From jdsw2002 at yahoo.com Fri May 4 03:05:51 2007 From: jdsw2002 at yahoo.com (jd) Date: Fri, 4 May 2007 03:05:51 -0700 (PDT) Subject: [paramiko] background process status (success/failure) Message-ID: <388353.65078.qm@web35802.mail.mud.yahoo.com> Hi everyone I am using channel.exec_command to start a process on a remote node in the background. example "sleep 600 &" (or some daemon like process) How do I know that the process in the background has started sucessfully and not exited with the error ? chan.recv_exit_status is a blocking call. (which would not work, when the process is started succesfully). Can I do some check on the channel? Thanks in advance. /Jd --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.lag.net/pipermail/paramiko/attachments/20070504/e27379ab/attachment.htm From sean.kane at hp.com Tue May 8 10:17:10 2007 From: sean.kane at hp.com (Kane, Sean) Date: Tue, 8 May 2007 17:17:10 -0000 Subject: [paramiko] remote to remote scp Message-ID: Does paramiko support remote server to remote server style transfers like you might do via scp on the command line with this: scp kane at www.bob.com:/tmp/test.txt josh at www.google.com:/tmp/cool.txt or an even simpler: scp www.bob.com:/tmp/test.txt www.google.com:/tmp/cool.txt Thanks, Sean ---- Sean P. Kane - Service/Support Onsite Engineer V VMS Operations Team - HP Digital Entertainment Services sean.kane at hp.com - Vancouver, WA, USA From slh at google.com Tue May 8 10:55:37 2007 From: slh at google.com (Stephen Lien Harrell) Date: Tue, 8 May 2007 10:55:37 -0700 Subject: [paramiko] remote to remote scp In-Reply-To: References: Message-ID: <15e8c5450705081055p3f98ee93nab28d699c1bb5f42@mail.gmail.com> From sean.kane at hp.com Tue May 8 10:58:03 2007 From: sean.kane at hp.com (Kane, Sean) Date: Tue, 8 May 2007 17:58:03 -0000 Subject: [paramiko] remote to remote scp In-Reply-To: <15e8c5450705081055p3f98ee93nab28d699c1bb5f42@mail.gmail.com> References: <15e8c5450705081055p3f98ee93nab28d699c1bb5f42@mail.gmail.com> Message-ID: That was my initial observation as well, but I wanted to double-check with folks who might know better, since that functionality would be very useful to me at the moment. Thanks, Sean ---- Sean P. Kane - Service/Support Onsite Engineer V VMS Operations Team - HP Digital Entertainment Services sean.kane at hp.com - Vancouver, WA, USA From: harrells at google.com [mailto:harrells at google.com] On Behalf Of Stephen Lien Harrell Sent: Tuesday, May 08, 2007 10:56 To: Kane, Sean Cc: paramiko at lag.net Subject: Re: [paramiko] remote to remote scp From wes at oxona.com Wed May 9 12:36:43 2007 From: wes at oxona.com (Wesley Augur) Date: Wed, 9 May 2007 15:36:43 -0400 Subject: [paramiko] Patch for SFTPClient to include "longname" in the file attributes Message-ID: I'm using paramiko as an SFTP client and am trying to access the owning user/group names (not IDs) for files. From what I can tell of the SFTP protocol v3, only the uid/gid is available in the file attributes, but according to http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-7 the user/group names are suggested to be included in the SSH_FXP_NAME longname field. SFTPClient.listdir_attr() currently ignores the longname field, would it be possible to have the field added to the SFTPAttributes? I attached a trivial patch which stores the longname field in the file attributes. Thanks for paramiko, it's incredibly useful! -- Wesley Augur wes at oxona.com -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko-r439+sftp_longname.patch Type: text/x-patch Size: 1402 bytes Desc: not available Url : http://mail.lag.net/pipermail/paramiko/attachments/20070509/59f5fd67/attachment.bin From robey at lag.net Sun May 20 15:57:43 2007 From: robey at lag.net (Robey Pointer) Date: Sun, 20 May 2007 15:57:43 -0700 Subject: [paramiko] Patch for SFTPClient to include "longname" in the file attributes In-Reply-To: References: Message-ID: On 9 May 2007, at 12:36, Wesley Augur wrote: > I'm using paramiko as an SFTP client and am trying to access the > owning user/group names (not IDs) for files. From what I can tell of > the SFTP protocol v3, only the uid/gid is available in the file > attributes, but according to > http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-7 the > user/group names are suggested to be included in the SSH_FXP_NAME > longname field. > > SFTPClient.listdir_attr() currently ignores the longname field, would > it be possible to have the field added to the SFTPAttributes? I > attached a trivial patch which stores the longname field in the file > attributes. Sounds fine to me -- applied! robey From robey at lag.net Sun May 20 17:24:50 2007 From: robey at lag.net (Robey Pointer) Date: Sun, 20 May 2007 17:24:50 -0700 Subject: [paramiko] How to use settimeout with from_transport In-Reply-To: <46327E34.9040209@bu.edu> References: <45F9B716.60709@bu.edu> <45F9FE6E.8070808@activestate.com> <45FAA17F.8060006@bu.edu> <378933AE-E927-4818-97CF-5B7CB18E623A@lag.net> <46327E34.9040209@bu.edu> Message-ID: <18BE554F-1447-4232-8906-3B2CA0689C55@lag.net> On 27 Apr 2007, at 15:50, James Bardin wrote: > Hi Robey, > > Just passing this along if you want to use it. > > I needed that ConnectTimeout option from openssh, so I added an > SSHClient.set_connect_timeout() method that sets the socket timeout > during the first connect, then transport takes over. > Another idea would be to move transport's connect outside of the > constructor, and give it a separate connect method, but this was > faster for my needs. I used this patch, but altered it slightly to just make 'timeout' an optional parameter to connect(). Thanks! robey From robey at lag.net Sun May 20 17:40:30 2007 From: robey at lag.net (Robey Pointer) Date: Sun, 20 May 2007 17:40:30 -0700 Subject: [paramiko] pid of command executed on remote machine. In-Reply-To: <907974.8545.qm@web35813.mail.mud.yahoo.com> References: <907974.8545.qm@web35813.mail.mud.yahoo.com> Message-ID: On 4 May 2007, at 2:49, jd wrote: > Hi everyone > > I would like to start the process on a remote node is > background, get its pid. How does one do that ? > I am using chan.exec_command If you know you're connecting to a unix machine, you can execute a shell command like: sh -c 'echo $$; ls' (Replace "ls" with whatever you're executing.) That will have it print out the pid ("$$") before executing the command. The SSH protocol doesn't otherwise expose a way to get the pid. robey From rafael.ugolini at vexcorp.com Mon May 21 14:11:20 2007 From: rafael.ugolini at vexcorp.com (Rafael Ugolini) Date: Mon, 21 May 2007 18:11:20 -0300 Subject: [paramiko] scp not sftp Message-ID: <46520AF8.3050605@vexcorp.com> Hi, I'm trying to use "scp" with paramiko to use with some old SSH version (v1). In SSHv1 scp work like this: 1. you open a connection to the remote host 2. create the channel 3. exec scp -t filename 4. send file info, eg. (C0664 SIZE 1\n) 5. send data How do you guys think I can do this ? I did 2 methods and i failed with both. ####### This one it stay on the first send def sendfile(self, path): chan = self._trans.open_session() chan.set_combine_stderr(True) f = file(path) print "send exec" chan.recv(1024) chan.send("execscp -v -t %s" % ) chan.recv(1024) print "send mode and data" chan.send("C0664 %d 1\n" % os.stat(path)[6]) chan.send("%s" % f.read()) print "close" chan.close() f.close() ####### Simple doesn't work def sendfile(self, path): chan = self._trans.open_session() chan.set_combine_stderr(True) f = file(path) print "send exec" chan.exec_command("scp -v -t %s" % ) chan.recv(1024) print "send mode and data" chan.send("C0664 %d 1\n" % os.stat(path)[6]) chan.send("%s" % f.read()) print "close" chan.close() f.close() Thanks, Rafael Ugolini From jdsw2002 at yahoo.com Mon May 21 16:47:21 2007 From: jdsw2002 at yahoo.com (jd) Date: Mon, 21 May 2007 16:47:21 -0700 (PDT) Subject: [paramiko] pid of command executed on remote machine. In-Reply-To: Message-ID: <230744.98508.qm@web35812.mail.mud.yahoo.com> Thanks Robey. In the given example, it would get the pid of the sh on the remote machine, I am looking for pid of 'ls' command. /Jd --- Robey Pointer wrote: > On 4 May 2007, at 2:49, jd wrote: > > > Hi everyone > > > > I would like to start the process on a remote > node is > > background, get its pid. How does one do that ? > > I am using chan.exec_command > > If you know you're connecting to a unix machine, you > can execute a > shell command like: > > sh -c 'echo $$; ls' > > (Replace "ls" with whatever you're executing.) That > will have it > print out the pid ("$$") before executing the > command. The SSH > protocol doesn't otherwise expose a way to get the > pid. > > robey > > ____________________________________________________________________________________Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 From robey at lag.net Mon May 21 18:32:17 2007 From: robey at lag.net (Robey Pointer) Date: Mon, 21 May 2007 18:32:17 -0700 Subject: [paramiko] pid of command executed on remote machine. In-Reply-To: <230744.98508.qm@web35812.mail.mud.yahoo.com> References: <230744.98508.qm@web35812.mail.mud.yahoo.com> Message-ID: <57739661-14BD-4FC8-8058-6D2D9CCC0C32@lag.net> On 21 May 2007, at 16:47, jd wrote: > Thanks Robey. > > In the given example, it would get the pid of the sh > on the remote machine, I am looking for pid of 'ls' > command. Check out "$!" -- I think that's what you want. I don't want to get into a whole discussion of bash esoterica, but I think what you want should all be doable from within the shell. :) robey From erick_bodine at comcast.net Mon May 21 20:18:20 2007 From: erick_bodine at comcast.net (erick_bodine at comcast.net) Date: Tue, 22 May 2007 03:18:20 +0000 Subject: [paramiko] scp not sftp Message-ID: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> Supposedly scp is just rcp over an ssh connection. Have you tried execing rcp instead of scp once you have the channel open? Perhaps a look at the source of PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html), they have a pscp utility that might yield some clues. -- --ERick -------------- Original message ---------------------- From: Rafael Ugolini > Hi, > > I'm trying to use "scp" with paramiko to use with some old SSH version (v1). > > In SSHv1 scp work like this: > 1. you open a connection to the remote host > 2. create the channel > 3. exec scp -t filename > 4. send file info, eg. (C0664 SIZE 1\n) > 5. send data > > How do you guys think I can do this ? > > I did 2 methods and i failed with both. > ####### This one it stay on the first send > def sendfile(self, path): > chan = self._trans.open_session() > chan.set_combine_stderr(True) > f = file(path) > print "send exec" > chan.recv(1024) > chan.send("execscp -v -t %s" % ) > chan.recv(1024) > print "send mode and data" > chan.send("C0664 %d 1\n" % os.stat(path)[6]) > chan.send("%s" % f.read()) > print "close" > chan.close() > f.close() > > > ####### Simple doesn't work > def sendfile(self, path): > chan = self._trans.open_session() > chan.set_combine_stderr(True) > f = file(path) > print "send exec" > chan.exec_command("scp -v -t %s" % ) > chan.recv(1024) > print "send mode and data" > chan.send("C0664 %d 1\n" % os.stat(path)[6]) > chan.send("%s" % f.read()) > print "close" > chan.close() > f.close() > > Thanks, > > Rafael Ugolini > > _______________________________________________ > paramiko mailing list > paramiko at lag.net > http://mail.lag.net/mailman/listinfo/paramiko From rafael.ugolini at vexcorp.com Tue May 22 07:08:26 2007 From: rafael.ugolini at vexcorp.com (Rafael Ugolini) Date: Tue, 22 May 2007 11:08:26 -0300 Subject: [paramiko] scp not sftp In-Reply-To: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> Message-ID: <4652F95A.4010603@vexcorp.com> It didn't help me too much, but i got it working now. def sendfile(self, path): chan = self._trans.open_session() f = file(path, "rb") chan.exec_command("scp -v -t %s\n" % path.split("/")[-1]) chan.send("C0664 %d 1\n" % os.stat(path)[6]) chan.sendall("%s" % ( f.read())) f.close() chan.close() Thanks, Rafael Ugolini erick_bodine at comcast.net wrote: > Supposedly scp is just rcp over an ssh connection. Have you tried execing rcp instead of scp once you have the channel open? Perhaps a look at the source of PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html), they have a pscp utility that might yield some clues. > > -- > --ERick > > -------------- Original message ---------------------- > From: Rafael Ugolini > >> Hi, >> >> I'm trying to use "scp" with paramiko to use with some old SSH version (v1). >> >> In SSHv1 scp work like this: >> 1. you open a connection to the remote host >> 2. create the channel >> 3. exec scp -t filename >> 4. send file info, eg. (C0664 SIZE 1\n) >> 5. send data >> >> How do you guys think I can do this ? >> >> I did 2 methods and i failed with both. >> ####### This one it stay on the first send >> def sendfile(self, path): >> chan = self._trans.open_session() >> chan.set_combine_stderr(True) >> f = file(path) >> print "send exec" >> chan.recv(1024) >> chan.send("execscp -v -t %s" % ) >> chan.recv(1024) >> print "send mode and data" >> chan.send("C0664 %d 1\n" % os.stat(path)[6]) >> chan.send("%s" % f.read()) >> print "close" >> chan.close() >> f.close() >> >> >> ####### Simple doesn't work >> def sendfile(self, path): >> chan = self._trans.open_session() >> chan.set_combine_stderr(True) >> f = file(path) >> print "send exec" >> chan.exec_command("scp -v -t %s" % ) >> chan.recv(1024) >> print "send mode and data" >> chan.send("C0664 %d 1\n" % os.stat(path)[6]) >> chan.send("%s" % f.read()) >> print "close" >> chan.close() >> f.close() >> >> Thanks, >> >> Rafael Ugolini >> >> _______________________________________________ >> paramiko mailing list >> paramiko at lag.net >> http://mail.lag.net/mailman/listinfo/paramiko >> > > > _______________________________________________ > paramiko mailing list > paramiko at lag.net > http://mail.lag.net/mailman/listinfo/paramiko > From jbardin at bu.edu Tue May 22 09:06:31 2007 From: jbardin at bu.edu (James Bardin) Date: Tue, 22 May 2007 12:06:31 -0400 Subject: [paramiko] scp not sftp In-Reply-To: <4652F95A.4010603@vexcorp.com> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> <4652F95A.4010603@vexcorp.com> Message-ID: <46531507.9030100@bu.edu> That's great! I tried this a while back and never got it working. I also noticed that putty's scp looks like it first tries to use sftp for the transfer. FYI, you can format the mode like: mode = os.stat(path).st_mode 'C%s' % oct(mode)[-4:] If you import the stat module you can also: mode = os.stat(path).st_mode 'C%s' % oct(stat.S_IMODE(mode)) Do you know what the 1 is for in the file info line? Thanks -jim Rafael Ugolini wrote: > It didn't help me too much, but i got it working now. > > def sendfile(self, path): > chan = self._trans.open_session() > f = file(path, "rb") > chan.exec_command("scp -v -t %s\n" % path.split("/")[-1]) > chan.send("C0664 %d 1\n" % os.stat(path)[6]) > chan.sendall("%s" % ( f.read())) > f.close() > chan.close() > > Thanks, > > Rafael Ugolini > > From robey at lag.net Wed May 23 10:07:53 2007 From: robey at lag.net (Robey Pointer) Date: Wed, 23 May 2007 10:07:53 -0700 Subject: [paramiko] scp not sftp In-Reply-To: <4652F95A.4010603@vexcorp.com> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> <4652F95A.4010603@vexcorp.com> Message-ID: <275E8464-9453-43F3-9564-762F501E6EAC@lag.net> On 22 May 2007, at 7:08, Rafael Ugolini wrote: > It didn't help me too much, but i got it working now. > > def sendfile(self, path): > chan = self._trans.open_session() > f = file(path, "rb") > chan.exec_command("scp -v -t %s\n" % path.split("/")[-1]) > chan.send("C0664 %d 1\n" % os.stat(path)[6]) > chan.sendall("%s" % ( f.read())) > f.close() > chan.close() Very cool. I didn't know that was how scp worked. By the way, you should be able to change this line: chan.sendall("%s" % ( f.read())) to this: chan.sendall(f.read()) robey From rafael.ugolini at vexcorp.com Wed May 23 10:55:09 2007 From: rafael.ugolini at vexcorp.com (Rafael Ugolini) Date: Wed, 23 May 2007 14:55:09 -0300 Subject: [paramiko] scp not sftp In-Reply-To: <46531507.9030100@bu.edu> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> <4652F95A.4010603@vexcorp.com> <46531507.9030100@bu.edu> Message-ID: <46547FFD.2000708@vexcorp.com> James Bardin wrote: > That's great! I tried this a while back and never got it working. > I also noticed that putty's scp looks like it first tries to use sftp > for the transfer. > > FYI, you can format the mode like: > mode = os.stat(path).st_mode > 'C%s' % oct(mode)[-4:] > > If you import the stat module you can also: > mode = os.stat(path).st_mode > 'C%s' % oct(stat.S_IMODE(mode)) > > Do you know what the 1 is for in the file info line? hmm, i don't remember why i put it there, but i was reading some docs and they were using something like scp -v -t . C0664 "size" "filename" but, the way i'm doing works. > > > Thanks > -jim > > > > Rafael Ugolini wrote: >> It didn't help me too much, but i got it working now. >> >> def sendfile(self, path): >> chan = self._trans.open_session() >> f = file(path, "rb") >> chan.exec_command("scp -v -t %s\n" % path.split("/")[-1]) >> chan.send("C0664 %d 1\n" % os.stat(path)[6]) >> chan.sendall("%s" % ( f.read())) >> f.close() >> chan.close() >> Thanks, >> >> Rafael Ugolini >> >> > From rafael.ugolini at vexcorp.com Wed May 23 10:57:46 2007 From: rafael.ugolini at vexcorp.com (Rafael Ugolini) Date: Wed, 23 May 2007 14:57:46 -0300 Subject: [paramiko] scp not sftp In-Reply-To: <46547EFD.4050808@bu.edu> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> <4652F95A.4010603@vexcorp.com> <275E8464-9453-43F3-9564-762F501E6EAC@lag.net> <46547EFD.4050808@bu.edu> Message-ID: <4654809A.10401@vexcorp.com> James Bardin wrote: > >> By the way, you should be able to change this line: >> >> chan.sendall("%s" % ( f.read())) >> >> to this: >> >> chan.sendall(f.read()) >> >> > > of course you may also want to add some sort of buffer, maybe > something like: > > s = f.read(32768) > while s: > chan.sendall(s) > s = f.read(32768) > > Robey, > Would you have an idea why I can get full 100Mb/s transfers with > scp, but only 50-70% of that with sftp? What kind of extra work is > sftp doing? > > Thanks > -jim > lol, true ! Robey, If you want, i can make a patch for paramiko, and you can put scp compatible with ssh version 1. Regards, Rafael Ugolini From jbardin at bu.edu Wed May 23 10:50:53 2007 From: jbardin at bu.edu (James Bardin) Date: Wed, 23 May 2007 13:50:53 -0400 Subject: [paramiko] scp not sftp In-Reply-To: <275E8464-9453-43F3-9564-762F501E6EAC@lag.net> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> <4652F95A.4010603@vexcorp.com> <275E8464-9453-43F3-9564-762F501E6EAC@lag.net> Message-ID: <46547EFD.4050808@bu.edu> > By the way, you should be able to change this line: > > chan.sendall("%s" % ( f.read())) > > to this: > > chan.sendall(f.read()) > > of course you may also want to add some sort of buffer, maybe something like: s = f.read(32768) while s: chan.sendall(s) s = f.read(32768) Robey, Would you have an idea why I can get full 100Mb/s transfers with scp, but only 50-70% of that with sftp? What kind of extra work is sftp doing? Thanks -jim From jbardin at bu.edu Wed May 23 11:57:37 2007 From: jbardin at bu.edu (James Bardin) Date: Wed, 23 May 2007 14:57:37 -0400 Subject: [paramiko] scp not sftp In-Reply-To: <46547FFD.2000708@vexcorp.com> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> <4652F95A.4010603@vexcorp.com> <46531507.9030100@bu.edu> <46547FFD.2000708@vexcorp.com> Message-ID: <46548EA1.4040905@bu.edu> Rafael Ugolini wrote: > James Bardin wrote: > >> That's great! I tried this a while back and never got it working. >> I also noticed that putty's scp looks like it first tries to use sftp >> for the transfer. >> >> FYI, you can format the mode like: >> mode = os.stat(path).st_mode >> 'C%s' % oct(mode)[-4:] >> >> If you import the stat module you can also: >> mode = os.stat(path).st_mode >> 'C%s' % oct(stat.S_IMODE(mode)) >> >> Do you know what the 1 is for in the file info line? >> > hmm, i don't remember why i put it there, but i was reading some docs and > they were using something like > > scp -v -t . > C0664 "size" "filename" > > > I was trying to read through the source of openssh scp.c (my c skills aren't much), and it looked like the "1" was a flag for last_file, for multiple file transfers. Maybe it's used with "scp -r -t directory" for recursive transfers. A patch like this would work fine against current openssh servers too. It seems openssh is still using the scp1 protocol, and the command that it issues on the other end is "scp -t ." It's only SSH2 (with scp2) that is incompatible. -jim From yateenjoshi at gmail.com Mon May 28 08:22:28 2007 From: yateenjoshi at gmail.com (Yateen Joshi) Date: Mon, 28 May 2007 20:52:28 +0530 Subject: [paramiko] Threads getting stuck during SFTP using Paramiko. In-Reply-To: <6b22365e0705260725j32bb8510x3d4b1c55131ebe90@mail.gmail.com> References: <6b22365e0705260725j32bb8510x3d4b1c55131ebe90@mail.gmail.com> Message-ID: <6b22365e0705280822o34869772r485a87f1c0a3eaf@mail.gmail.com> Additionally, If I disable prefetch, the problem is not seen. Yateen V. Joshi On 5/26/07, Yateen Joshi wrote: > > Hi, > > > > The simple nature of the problem is as follows ? > > > > I am periodically getting files from a remote machine (which is having > openSSH) using Paramiko sftp client as a part of my python script. > > The files keep on generating at the remote server and my application > fetches it on a regular basis. It is observed that the application gets > stuck after some time and it no longer fetches any file. > > > > Here is the analysis ? > > > > I observed in the paramiko logs that it is stuck after a certain number of > rekeys. To easily reproduce the problem, I reduced the number of bytes and > packets after which the rekey happens. Default is 2 power 30, I made them 2 > power 13 and the problem gets reproduced easily. > > Just to verify my logic, I disabled this rekeying mechanism (instead of > incrementing the bytes and packets in read_message, I kept them constant) > and found the problem was NOT reproduced. > > > > Since my application was running on a Solaris (9) machine, I took a gcore > of the same and found that one of the threads was stuck. I put more logs in > paramiko code, and found that it got stuck in channel::_feed() method while > trying to acquire lock. > > > > Here are the paramiko logs - > > > > DEB [20070526-19:21:47.001] thr=1 paramiko.transport.1 : releasing lock > - channel::_feed > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport.1 : released lock - > channel::_feed > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport : calling > send_kex_init in need key > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport : acquiring clear > to send lock - _send_kex_init > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport : acquired clear to > send lock - _send_kex_init > > DEB [20070526-19:21:47.003] thr=2 paramiko.transport.1.sftp : > stat('/records/edr/NC38_RB_05262007190750_000_000057032.gz') > > DEB [20070526-19:21:47.003] thr=1 paramiko.transport : releasing lock - > clear to send lock _send_kex_init > > DEB [20070526-19:21:47.004] thr=2 paramiko.transport.1 : acquiring lock > - channel::send > > DEB [20070526-19:21:47.004] thr=1 paramiko.transport : released lock - > clear to send lock _send_kex_init > > DEB [20070526-19:21:47.005] thr=2 paramiko.transport.1 : acquired lock - > channel::send > > DEB [20070526-19:21:47.007] thr=1 paramiko.transport : coming out of > _send_kex_init > > DEB [20070526-19:21:47.008] thr=1 paramiko.transport : called > send_kex_init in need key > > DEB [20070526-19:21:47.011] thr=1 paramiko.transport.1 : acquiring lock > - channel::_feed > > > > > > Here is the dbx output ? > > > > Reading parser.so > > t at 2 (l at 2) terminated by signal 0 (UNKNOWN SIGNAL) > > 0xfee354b0: __lwp_park+0x0010: ta 8 > > Current function is PyThread_acquire_lock > > dbx.11: warning: can't find file "/sol10/SOURCES/S8/Python-2.4.2 > /Python/thread_pthread.h" > > dbx.11: warning: see `help finding-files' > > (dbx.11) > > (dbx.11) where > > current thread: t at 2 > > dbx.11: warning: invalid type for LCSYM/STSYM stab: > /export/home/edrserver/ess/3rdparty/python/solaris/bin/python2.4:Objects/classobject.c > stab #10921 docstr:V(49,10) > > [1] __lwp_park(0x0, 0x0, 0x0, 0x1, 0xfee48000, 0x206288), at 0xfee354b0 > > [2] cond_wait_queue(0x2035c0, 0xfee48c08, 0x0, 0x0, 0xfed70200, > 0xfee48000), at 0xfee326b8 > > [3] _cond_wait_cancel(0x2035c0, 0x2035d0, 0x7c, 0xfed29138, 0x140000, > 0x0), at 0xfee32e74 > > [4] _pthread_cond_wait(0x2035c0, 0x2035d0, 0xfe8fb08c, 0x0, 0x1b, 0x1), > at 0xfee32eb0 > > =>[5] PyThread_acquire_lock(lock = 0x2035b8, waitflag = 2110928), line 416 > in "thread_pthread.h" > > [6] lock_PyThread_acquire_lock(self = 0x17d4c0, args = 0x141030), line > 63 in "threadmodule.c" > > [7] PyCFunction_Call(func = 0x334198, arg = 0x141030, kw = (nil)), line > 94 in "methodobject.c" > > [8] call_function(pp_stack = 0xfe8fb290, oparg = 0), line 3558 in " > ceval.c" > > [9] PyEval_EvalFrame(f = 0x59deb0), line 2163 in "ceval.c" > > [10] PyEval_EvalCodeEx(co = 0x278060, globals = (nil), locals = 0x81da0, > args = 0x327b54, argcount = 2, kws = (nil), kwcount = 0, defs = (nil), > defcount = 0, closure = (nil)), line 2736 in " ceval.c" > > [11] function_call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), line > 548 in "funcobject.c" > > [12] PyObject_Call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), line > 1756 in "abstract.c" > > [13] instancemethod_call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), > line 2447 in "classobject.c " > > [14] PyObject_Call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), line > 1756 in "abstract.c" > > [15] do_call(func = 0x1e5378, pp_stack = 0xfe8fb890, na = 2, nk = > 3308360), line 3766 in "ceval.c " > > [16] call_function(pp_stack = 0xfe8fb890, oparg = 2), line 3581 in " > ceval.c" > > [17] PyEval_EvalFrame(f = 0x5f0488), line 2163 in "ceval.c" > > [18] fast_function(func = 0x3320b0, pp_stack = 0x18d420, n = 1, na = > 6211252, nk = 6227080), line 3640 in " ceval.c" > > [19] call_function(pp_stack = 0xfe8fba38, oparg = 1), line 3579 in " > ceval.c" > > [20] PyEval_EvalFrame(f = 0x18d2c0), line 2163 in "ceval.c" > > [21] PyEval_EvalCodeEx(co = 0x2238a0, globals = (nil), locals = 0x81da0, > args = 0x1edd9c, argcount = 1, kws = (nil), kwcount = 0, defs = (nil), > defcount = 0, closure = (nil)), line 2736 in " ceval.c" > > [22] function_call(func = 0x244430, arg = 0x1edd90, kw = (nil)), line > 548 in "funcobject.c" > > [23] PyObject_Call(func = 0x244430, arg = 0x1edd90, kw = (nil)), line > 1756 in "abstract.c" > > [24] instancemethod_call(func = 0x244430, arg = 0x1edd90, kw = (nil)), > line 2447 in "classobject.c " > > [25] PyObject_Call(func = 0x244430, arg = 0x1edd90, kw = (nil)), line > 1756 in " abstract.c" > > [26] PyEval_CallObjectWithKeywords(func = 0x31d828, arg = 0x141030, kw = > (nil)), line 3425 in "ceval.c " > > [27] t_bootstrap(boot_raw = 0x6abfd8), line 434 in "threadmodule.c" > > (dbx.11) threads > > t at 1 a l at 1 ?() running in _poll() > > > t at 2 b l at 2 t_bootstrap() sleep on 0x2035c0 in __lwp_park() > > (dbx.11) > > (dbx.11) > > (dbx.11) > > (dbx.11) > > (dbx.11) > > (dbx.11) > > (dbx.11) thread -blockedby t at 1 > > Thread t at 1 is not asleep > > (dbx.11) thread -blockedby t at 2 > > Thread t at 2 is blocked by: > > 0x002035c0 (0x2035c0): thread condition variable > > (dbx.11) thread -blocks t at 1 > > Locks held by t at 1: > > (dbx.11) thread -blocks t at 2 > > Locks held by t at 2: > > (dbx.11) thread -info t at 1 > > Thread t at 1 (0xfed70000) at priority 0 > > state: active on l at 1 > > base function: 0x0: 0x00000000() stack: 0xffc00000[8388608] > > flags: (none) > > masked signals: (none) > > Currently active in _poll > > (dbx.11) thread -info t at 2 > > Thread t at 2 (0xfed70200) at priority 0 > > state: asleep on 0x002035c0 (0x2035c0): thread condition variable > > > base function: 0xc54f8: t_bootstrap() stack: 0xfe8fc000[1032192] > > flags: BOUND|DETACHED|SUSPENDED > > masked signals: (none) > > Currently inactive in __lwp_park > > (dbx.11) > > > > > > As can be seen from the dbx and paramiko logs, thread is > channel::_feed() and thread2 is channel::send(). > > The thread 2 (send) is waiting in an infinite while loop (please see code > below) to get a variable set (clear_to_send), however, that will be set > after some data is received. The other thread that might receive the data is > now stuck in channel::_feed(). > > transport.py - > def _send_user_message(self, data): > """ > send a message, but block if we're in key negotiation. this is > used > for user-initiated requests. > """ > while True: > self.clear_to_send.wait(0.1) > if not self.active: > self._log(DEBUG, 'Dropping user packet because connection > is dea > d.') > return > self.clear_to_send_lock.acquire() > if self.clear_to_send.isSet(): > break > self.clear_to_send_lock.release() > try: > self._send_message(data) > finally: > self.clear_to_send_lock.release() > > > I tried to use pdb (python debugger), however, did not have any luck. Can > you give any pointers as to why this is happening and reason for the thread > getting stuck? Also, any pointers why this is related to rekeying? > > > > Appreciating your response in advance, > > > > Best regards, > > > > > > Yateen Vishnu Joshi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.lag.net/pipermail/paramiko/attachments/20070528/49cf7d25/attachment.htm From robey at lag.net Tue May 29 09:47:34 2007 From: robey at lag.net (Robey Pointer) Date: Tue, 29 May 2007 09:47:34 -0700 Subject: [paramiko] scp not sftp In-Reply-To: <4654809A.10401@vexcorp.com> References: <052220070318.27770.465260FB000ED19300006C7A22058864420A02070B010DA1050C079D0A@comcast.net> <4652F95A.4010603@vexcorp.com> <275E8464-9453-43F3-9564-762F501E6EAC@lag.net> <46547EFD.4050808@bu.edu> <4654809A.10401@vexcorp.com> Message-ID: On 23 May 2007, at 10:57, Rafael Ugolini wrote: > James Bardin wrote: >> >>> By the way, you should be able to change this line: >>> >>> chan.sendall("%s" % ( f.read())) >>> >>> to this: >>> >>> chan.sendall(f.read()) >>> >>> >> >> of course you may also want to add some sort of buffer, maybe >> something like: >> >> s = f.read(32768) >> while s: >> chan.sendall(s) >> s = f.read(32768) >> >> Robey, >> Would you have an idea why I can get full 100Mb/s transfers with >> scp, but only 50-70% of that with sftp? What kind of extra work is >> sftp doing? It's almost certainly the round-trip latency. SFTP tends to send-and- wait: it sends one chunk of a file, then waits for it to be acknowledged. You can get around that by turning on prefetch or pipelining. > Robey, > > If you want, i can make a patch for paramiko, and you can put scp > compatible with ssh version 1. That would be cool! It probably wouldn't be compatible with SSH version 1, though. SSH v1 uses a different transport protocol. I guess what's happening is that it's using scp v1 over an SSH v2 transport. robey From yateenjoshi at gmail.com Thu May 31 03:36:56 2007 From: yateenjoshi at gmail.com (Yateen Joshi) Date: Thu, 31 May 2007 16:06:56 +0530 Subject: [paramiko] Threads getting stuck during SFTP using Paramiko. Message-ID: <6b22365e0705310336t7e3954b4hf62af229bc879cde@mail.gmail.com> Though I removed call to prefetch, (to avoid the threads stuck issue), the speed of fetching is reduced a lot. Looks like there is no alternative to prefetch for getting (sftp) files at a good speed. However, if prefetch is used, I am seeing below issue. Does anyone have any idea as to why this problem is seen? (prefetch initiates another thread that is probably getting locked with an existing thread). Any inputs? Thanks and regards, Yateen V. Joshi Today's Topics: > > 1. Re: Threads getting stuck during SFTP using Paramiko. > (Yateen Joshi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 28 May 2007 20:52:28 +0530 > From: "Yateen Joshi" > Subject: Re: [paramiko] Threads getting stuck during SFTP using > Paramiko. > To: paramiko at lag.net > Message-ID: > <6b22365e0705280822o34869772r485a87f1c0a3eaf at mail.gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Additionally, > > If I disable prefetch, the problem is not seen. > > Yateen V. Joshi > > > On 5/26/07, Yateen Joshi wrote: > > > > Hi, > > > > > > > > The simple nature of the problem is as follows ? > > > > > > > > I am periodically getting files from a remote machine (which is having > > openSSH) using Paramiko sftp client as a part of my python script. > > > > The files keep on generating at the remote server and my application > > fetches it on a regular basis. It is observed that the application gets > > stuck after some time and it no longer fetches any file. > > > > > > > > Here is the analysis ? > > > > > > > > I observed in the paramiko logs that it is stuck after a certain number > of > > rekeys. To easily reproduce the problem, I reduced the number of bytes > and > > packets after which the rekey happens. Default is 2 power 30, I made > them 2 > > power 13 and the problem gets reproduced easily. > > > > Just to verify my logic, I disabled this rekeying mechanism (instead of > > incrementing the bytes and packets in read_message, I kept them > constant) > > and found the problem was NOT reproduced. > > > > > > > > Since my application was running on a Solaris (9) machine, I took a > gcore > > of the same and found that one of the threads was stuck. I put more logs > in > > paramiko code, and found that it got stuck in channel::_feed() method > while > > trying to acquire lock. > > > > > > > > Here are the paramiko logs - > > > > > > > > DEB [20070526-19:21:47.001] thr=1 paramiko.transport.1 : releasing > lock > > - channel::_feed > > > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport.1 : released lock > - > > channel::_feed > > > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport : calling > > send_kex_init in need key > > > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport : acquiring clear > > to send lock - _send_kex_init > > > > DEB [20070526-19:21:47.002] thr=1 paramiko.transport : acquired clear > to > > send lock - _send_kex_init > > > > DEB [20070526-19:21:47.003] thr=2 paramiko.transport.1.sftp : > > stat('/records/edr/NC38_RB_05262007190750_000_000057032.gz') > > > > DEB [20070526-19:21:47.003] thr=1 paramiko.transport : releasing lock > - > > clear to send lock _send_kex_init > > > > DEB [20070526-19:21:47.004] thr=2 paramiko.transport.1 : acquiring > lock > > - channel::send > > > > DEB [20070526-19:21:47.004] thr=1 paramiko.transport : released lock - > > clear to send lock _send_kex_init > > > > DEB [20070526-19:21:47.005] thr=2 paramiko.transport.1 : acquired lock > - > > channel::send > > > > DEB [20070526-19:21:47.007] thr=1 paramiko.transport : coming out of > > _send_kex_init > > > > DEB [20070526-19:21:47.008] thr=1 paramiko.transport : called > > send_kex_init in need key > > > > DEB [20070526-19:21:47.011] thr=1 paramiko.transport.1 : acquiring > lock > > - channel::_feed > > > > > > > > > > > > Here is the dbx output ? > > > > > > > > Reading parser.so > > > > t at 2 (l at 2) terminated by signal 0 (UNKNOWN SIGNAL) > > > > 0xfee354b0: __lwp_park+0x0010: ta 8 > > > > Current function is PyThread_acquire_lock > > > > dbx.11: warning: can't find file "/sol10/SOURCES/S8/Python-2.4.2 > > /Python/thread_pthread.h" > > > > dbx.11: warning: see `help finding-files' > > > > (dbx.11) > > > > (dbx.11) where > > > > current thread: t at 2 > > > > dbx.11: warning: invalid type for LCSYM/STSYM stab: > > > /export/home/edrserver/ess/3rdparty/python/solaris/bin/python2.4:Objects/classobject.c > > stab #10921 docstr:V(49,10) > > > > [1] __lwp_park(0x0, 0x0, 0x0, 0x1, 0xfee48000, 0x206288), at > 0xfee354b0 > > > > [2] cond_wait_queue(0x2035c0, 0xfee48c08, 0x0, 0x0, 0xfed70200, > > 0xfee48000), at 0xfee326b8 > > > > [3] _cond_wait_cancel(0x2035c0, 0x2035d0, 0x7c, 0xfed29138, 0x140000, > > 0x0), at 0xfee32e74 > > > > [4] _pthread_cond_wait(0x2035c0, 0x2035d0, 0xfe8fb08c, 0x0, 0x1b, > 0x1), > > at 0xfee32eb0 > > > > =>[5] PyThread_acquire_lock(lock = 0x2035b8, waitflag = 2110928), line > 416 > > in "thread_pthread.h" > > > > [6] lock_PyThread_acquire_lock(self = 0x17d4c0, args = 0x141030), line > > 63 in "threadmodule.c" > > > > [7] PyCFunction_Call(func = 0x334198, arg = 0x141030, kw = (nil)), > line > > 94 in "methodobject.c" > > > > [8] call_function(pp_stack = 0xfe8fb290, oparg = 0), line 3558 in " > > ceval.c" > > > > [9] PyEval_EvalFrame(f = 0x59deb0), line 2163 in "ceval.c" > > > > [10] PyEval_EvalCodeEx(co = 0x278060, globals = (nil), locals = > 0x81da0, > > args = 0x327b54, argcount = 2, kws = (nil), kwcount = 0, defs = (nil), > > defcount = 0, closure = (nil)), line 2736 in " ceval.c" > > > > [11] function_call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), line > > 548 in "funcobject.c" > > > > [12] PyObject_Call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), line > > 1756 in "abstract.c" > > > > [13] instancemethod_call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), > > line 2447 in "classobject.c " > > > > [14] PyObject_Call(func = 0x27ea70, arg = 0x327b48, kw = (nil)), line > > 1756 in "abstract.c" > > > > [15] do_call(func = 0x1e5378, pp_stack = 0xfe8fb890, na = 2, nk = > > 3308360), line 3766 in "ceval.c " > > > > [16] call_function(pp_stack = 0xfe8fb890, oparg = 2), line 3581 in " > > ceval.c" > > > > [17] PyEval_EvalFrame(f = 0x5f0488), line 2163 in "ceval.c" > > > > [18] fast_function(func = 0x3320b0, pp_stack = 0x18d420, n = 1, na = > > 6211252, nk = 6227080), line 3640 in " ceval.c" > > > > [19] call_function(pp_stack = 0xfe8fba38, oparg = 1), line 3579 in " > > ceval.c" > > > > [20] PyEval_EvalFrame(f = 0x18d2c0), line 2163 in "ceval.c" > > > > [21] PyEval_EvalCodeEx(co = 0x2238a0, globals = (nil), locals = > 0x81da0, > > args = 0x1edd9c, argcount = 1, kws = (nil), kwcount = 0, defs = (nil), > > defcount = 0, closure = (nil)), line 2736 in " ceval.c" > > > > [22] function_call(func = 0x244430, arg = 0x1edd90, kw = (nil)), line > > 548 in "funcobject.c" > > > > [23] PyObject_Call(func = 0x244430, arg = 0x1edd90, kw = (nil)), line > > 1756 in "abstract.c" > > > > [24] instancemethod_call(func = 0x244430, arg = 0x1edd90, kw = (nil)), > > line 2447 in "classobject.c " > > > > [25] PyObject_Call(func = 0x244430, arg = 0x1edd90, kw = (nil)), line > > 1756 in " abstract.c" > > > > [26] PyEval_CallObjectWithKeywords(func = 0x31d828, arg = 0x141030, kw > = > > (nil)), line 3425 in "ceval.c " > > > > [27] t_bootstrap(boot_raw = 0x6abfd8), line 434 in "threadmodule.c" > > > > (dbx.11) threads > > > > t at 1 a l at 1 ?() running in _poll() > > > > > t at 2 b l at 2 t_bootstrap() sleep on 0x2035c0 in __lwp_park() > > > > (dbx.11) > > > > (dbx.11) > > > > (dbx.11) > > > > (dbx.11) > > > > (dbx.11) > > > > (dbx.11) > > > > (dbx.11) thread -blockedby t at 1 > > > > Thread t at 1 is not asleep > > > > (dbx.11) thread -blockedby t at 2 > > > > Thread t at 2 is blocked by: > > > > 0x002035c0 (0x2035c0): thread condition variable > > > > (dbx.11) thread -blocks t at 1 > > > > Locks held by t at 1: > > > > (dbx.11) thread -blocks t at 2 > > > > Locks held by t at 2: > > > > (dbx.11) thread -info t at 1 > > > > Thread t at 1 (0xfed70000) at priority 0 > > > > state: active on l at 1 > > > > base function: 0x0: 0x00000000() stack: 0xffc00000[8388608] > > > > flags: (none) > > > > masked signals: (none) > > > > Currently active in _poll > > > > (dbx.11) thread -info t at 2 > > > > Thread t at 2 (0xfed70200) at priority 0 > > > > state: asleep on 0x002035c0 (0x2035c0): thread condition > variable > > > > > > base function: 0xc54f8: t_bootstrap() stack: 0xfe8fc000[1032192] > > > > flags: BOUND|DETACHED|SUSPENDED > > > > masked signals: (none) > > > > Currently inactive in __lwp_park > > > > (dbx.11) > > > > > > > > > > > > As can be seen from the dbx and paramiko logs, thread is > > channel::_feed() and thread2 is channel::send(). > > > > The thread 2 (send) is waiting in an infinite while loop (please see > code > > below) to get a variable set (clear_to_send), however, that will be set > > after some data is received. The other thread that might receive the > data is > > now stuck in channel::_feed(). > > > > transport.py - > > def _send_user_message(self, data): > > """ > > send a message, but block if we're in key negotiation. this is > > used > > for user-initiated requests. > > """ > > while True: > > self.clear_to_send.wait(0.1) > > if not self.active: > > self._log(DEBUG, 'Dropping user packet because > connection > > is dea > > d.') > > return > > self.clear_to_send_lock.acquire() > > if self.clear_to_send.isSet(): > > break > > self.clear_to_send_lock.release() > > try: > > self._send_message(data) > > finally: > > self.clear_to_send_lock.release() > > > > > > I tried to use pdb (python debugger), however, did not have any luck. > Can > > you give any pointers as to why this is happening and reason for the > thread > > getting stuck? Also, any pointers why this is related to rekeying? > > > > > > > > Appreciating your response in advance, > > > > > > > > Best regards, > > > > > > > > > > > > Yateen Vishnu Joshi > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.lag.net/pipermail/paramiko/attachments/20070528/49cf7d25/attachment.html > > ------------------------------ > > _______________________________________________ > paramiko mailing list > paramiko at lag.net > http://mail.lag.net/mailman/listinfo/paramiko > > End of paramiko Digest, Vol 29, Issue 8 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.lag.net/pipermail/paramiko/attachments/20070531/b0ce40fd/attachment.htm