On Fri, Jan 29, 2010 at 12:57 PM, Peter Stuge <peter_at_stuge.se> wrote:
> What do you mean by process status?
>
I mean to retrieve information about the running process.
> Oh, and how can you be sure that the remote server even *supports*
> processes? You might be talking to an SSHD which doesn't have any
> such concept.
>
You are right I am happily assuming that a shell exist which maybe a false
assumption.
> What exactly do you want to do?
>
I am trying to write a user interface for a network backup utility. So all
my user interface does is executes the apps on the remote servers and then
the apps takes care of the backups. So it's a mess because once the
execution starts there is very little the interface can do to control the
apps, basically just sit back and hope it all goes well. So I read stderr
and stdin from ssh channel to get progress and such, but with the /bin/sh
method it's hard to know whether the process even finished because i need to
monitor processes with shell commands like ps and echo i guess. But most
importantly I need to know at least every second if the process is running
so i need to issue echo $ to get a pid. Anyways there are my obstacles, I
would hate using shell commands to get that kind of info cause it's
cumbersome but what else can i do ?
If you can assume that the remote end will always be Linux you can of
> course interface with /proc on the remote host in a separate channel.
> All you need then is the pid of the process in the first channel,
> which you might be able to retrieve easily. (SSH does not offer any
> way to do it though, you have to do it on your own.)
>
This maybe a good solution, I must say that when i tried to have more then
one non-blocking channel on the same session i was getting crashes and
erratic behaviour, but this maybe due to some of my own code. There fore I
usually establish more then one session.
> The latter is extremely unstable, because you are most likely making
> a great many assumptions about the shell on the remote server - while
> the former is extremely stable, because it makes *NO* assumptions
> about shells on the remote server. The former method only needs to
> rely on SSH protocol.
>
I hear you.
> It's quite possible that there are easy ways to increase performance
> using the former method. libssh2 has sub-optimal performance in many
> cases, so there might be a fix if you look into this some more.
>
Yes, I could do that if I had time later.
Inspired by you, I did find the solution to using sscanf to parse the
buffer, thanks!
A.Mark
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-01-30