attach to process by pid?

Discussion in 'Python' started by Danny Shevitz, Mar 8, 2011.

  1. Howdy,

    Is there any way to attach to an already running process by pid? I want to send
    commands from python to an application that is already running. I don't want to
    give the command name to subprocess.Popen.

    thanks,
    Danny
     
    Danny Shevitz, Mar 8, 2011
    #1
    1. Advertising

  2. I think he wants to attach to another process's stdin/stdout and
    read/write from/to them.
    I don't know if this is possible but it would be a great addition for psutil.


    --- Giampaolo
    http://code.google.com/p/pyftpdlib/
    http://code.google.com/p/psutil/




    2011/3/10 Miki Tebeka <>:
    >> Is there any way to attach to an already running process by pid? I want to send
    >> commands from python to an application that is already running. I don't want to
    >> give the command name to subprocess.Popen.

    > We probably need more information. What do you mean by "send commands"? (What was your work flow if you could give the command name to Popen?)
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
     
    Giampaolo Rodolà, Mar 10, 2011
    #2
    1. Advertising

  3. Danny Shevitz

    Nobody Guest

    On Thu, 10 Mar 2011 20:22:11 +0100, Giampaolo Rodolà wrote:

    > I think he wants to attach to another process's stdin/stdout and
    > read/write from/to them.
    > I don't know if this is possible but it would be a great addition for psutil.


    It's not even a meaningful concept, let alone possible.
     
    Nobody, Mar 10, 2011
    #3
  4. On 10.03.2011 23:25, Nobody wrote:
    > On Thu, 10 Mar 2011 20:22:11 +0100, Giampaolo Rodolà wrote:
    >
    >> I think he wants to attach to another process's stdin/stdout and
    >> read/write from/to them.
    >> I don't know if this is possible but it would be a great addition for psutil.

    >
    > It's not even a meaningful concept, let alone possible.


    Unless I misunderstand something, it is possible (at least on Linux):

    Two terminal windows:

    1:
    alex@frittenbude:~$ grep foobar

    2:
    alex@frittenbude:~$ ps ax|grep 'grep foobar'
    13075 pts/4 S+ 0:00 grep --color=auto grep foobar
    alex@frittenbude:~$ echo foobar > /proc/13075/fd/0

    That this is *highly* system dependent, problematic in many regards
    and just terrible hackery is another issue.
     
    Alexander Kapps, Mar 10, 2011
    #4
  5. Danny Shevitz

    James Mills Guest

    On Fri, Mar 11, 2011 at 8:55 AM, Alexander Kapps <> wrote:
    > On 10.03.2011 23:25, Nobody wrote:
    > Unless I misunderstand something, it is possible (at least on Linux):
    >
    > Two terminal windows:
    >
    > 1:
    > alex@frittenbude:~$ grep foobar
    >
    > 2:
    > alex@frittenbude:~$ ps ax|grep 'grep foobar'
    > 13075 pts/4    S+     0:00 grep --color=auto grep foobar
    > alex@frittenbude:~$ echo foobar > /proc/13075/fd/0


    This works fine on the Linux platform (perhaps other UNIX-like
    platforms have similar concepts). You're simply writing to
    the processes's stdin (file descriptor of 0)

    Probably not a portable solution.

    cheers
    James

    --
    -- James Mills
    --
    -- "Problems are solved by method"
     
    James Mills, Mar 10, 2011
    #5
  6. On 2011-03-10, Alexander Kapps <> wrote:
    > On 10.03.2011 23:25, Nobody wrote:
    >> On Thu, 10 Mar 2011 20:22:11 +0100, Giampaolo Rodol?? wrote:
    >>
    >>> I think he wants to attach to another process's stdin/stdout and
    >>> read/write from/to them. I don't know if this is possible but it
    >>> would be a great addition for psutil.

    >>
    >> It's not even a meaningful concept, let alone possible.

    >
    > Unless I misunderstand something, it is possible (at least on Linux):


    Sometimes. [See below.]

    > Two terminal windows:
    >
    > 1:
    > alex@frittenbude:~$ grep foobar
    >
    > 2:
    > alex@frittenbude:~$ ps ax|grep 'grep foobar'
    > 13075 pts/4 S+ 0:00 grep --color=auto grep foobar
    > alex@frittenbude:~$ echo foobar > /proc/13075/fd/0
    >
    > That this is *highly* system dependent, problematic in many regards
    > and just terrible hackery is another issue.


    That doesn't work for me:

    Terminal 1:

    $ grep foobar
    asdf

    Terminal 1:
    $ ps axf | grep "grep foobar"
    7203 pts/4 S+ 0:00 \_ grep foobar
    7205 pts/5 S+ 0:00 \_ grep grep foobar

    $ echo "asdf" >/proc/7203/fd/0

    What the echo did was write to the tty device from which the "grep" is
    reading. The string "asdf" went directly to the tty. It didn't go to
    grep's stdin (grep wouldn't have displayed it).


    It _does_ work on processes who's stdin is an anonymous pipe:

    terminal window 1:

    $ (while sleep 1; do date; done) | grep foobar
    foobar
    asdffoobarqwer

    terminal window 2:

    $ ps axf | grep "grep foobar"
    7229 pts/4 S+ 0:00 \_ grep foobar
    7268 pts/5 S+ 0:00 \_ grep grep foobar
    $ echo "asdf" >/proc/7229/fd/0
    $ echo "foobar" >/proc/7229/fd/0
    $ echo "qwer" >/proc/7229/fd/0
    $ echo "asdffoobarqwer" >/proc/7229/fd/0

    We know that the data written to /proc/7229/fd/0 was going to grep's
    stdin, since lines with foobar were printed and lines without weren't.

    I'll do an 'echo "hi there" >/proc/fd/7346/fd/0 where 7346 is the pid
    of the instance of the "jed" text editor that I'm using to edit this
    post. The "hi there" string showed up in my terminal window, but it
    didn't actually get inserted in the file, because "jed" didn't see it.

    /proc/fd/7346/fd/0 points to /dev/pts/0. Writing to /dev/pts/0 sends
    data to the terminal window, _not_ to process 7346's stdin. Writing
    to /proc/fd/7346/fd/1 does the same thing. Writing to
    /proc/fd/7346/fd/2 sends the data to the tty where the write was done,
    since /proc/fd/7346/fd/2 points to /dev/tty, and /dev/tty points to
    different things depending on who's doing the writing.

    There are _some_ cases where you can write to /proc/<pid>/fd/0 and the
    program specified by <pid> sees the data on it's stdin. But, it doesn't
    work in many common cases.

    --
    Grant Edwards grant.b.edwards Yow! Did an Italian CRANE
    at OPERATOR just experience
    gmail.com uninhibited sensations in
    a MALIBU HOT TUB?
     
    Grant Edwards, Mar 10, 2011
    #6
  7. On 2011-03-10, James Mills <> wrote:
    > On Fri, Mar 11, 2011 at 8:55 AM, Alexander Kapps <> wrote:
    >> On 10.03.2011 23:25, Nobody wrote:
    >> Unless I misunderstand something, it is possible (at least on Linux):
    >>
    >> Two terminal windows:
    >>
    >> 1:
    >> alex@frittenbude:~$ grep foobar
    >>
    >> 2:
    >> alex@frittenbude:~$ ps ax|grep 'grep foobar'
    >> 13075 pts/4 ?? ??S+ ?? ?? 0:00 grep --color=auto grep foobar
    >> alex@frittenbude:~$ echo foobar > /proc/13075/fd/0

    >
    > This works fine on the Linux platform


    No it doesn't. Try writing something other than "foobar".

    --
    Grant Edwards grant.b.edwards Yow! An INK-LING? Sure --
    at TAKE one!! Did you BUY any
    gmail.com COMMUNIST UNIFORMS??
     
    Grant Edwards, Mar 10, 2011
    #7
  8. Danny Shevitz

    James Mills Guest

    On Fri, Mar 11, 2011 at 9:30 AM, Grant Edwards <> wrote:
    > No it doesn't.  Try writing something other than "foobar".


    You've demonstrated a case where this doesn't work :)

    cheers
    James

    --
    -- James Mills
    --
    -- "Problems are solved by method"
     
    James Mills, Mar 10, 2011
    #8
  9. Danny Shevitz

    Nobody Guest

    On Thu, 10 Mar 2011 23:55:51 +0100, Alexander Kapps wrote:

    >>> I think he wants to attach to another process's stdin/stdout and
    >>> read/write from/to them.
    >>> I don't know if this is possible but it would be a great addition for
    >>> psutil.

    >>
    >> It's not even a meaningful concept, let alone possible.

    >
    > Unless I misunderstand something,


    You do ...

    > it is possible (at least on Linux):
    >
    > Two terminal windows:
    >
    > 1:
    > alex@frittenbude:~$ grep foobar
    >
    > 2:
    > alex@frittenbude:~$ ps ax|grep 'grep foobar'
    > 13075 pts/4 S+ 0:00 grep --color=auto grep foobar
    > alex@frittenbude:~$ echo foobar > /proc/13075/fd/0


    The /proc/<pid>/fd/<n> pseudo-files are just aliases for whatever "object"
    (file, device, socket, ...) is attached to that descriptor. Writing to the
    pseudo-file writes to the file, not to the descriptor. E.g.:

    $ > foo.txt
    $ sleep 100 < foo.txt &
    [1] 17380
    $ cat foo.txt
    $ echo hello > /proc/17380/fd/0
    $ cat foo.txt
    hello

    Similarly, if the process' standard input is a terminal, writing to
    /proc/<pid>/fd/0 will write to the terminal. It will not cause the data to
    appear on the process' standard input.

    There are a few situations where it will work (for some values of "work").

    E.g. in the case where standard input is a file, writing to .../fd/0 will
    write to the file. If you open .../fd/0 in append mode (or if the process
    hasn't started reading it yet), the next time the process reads from the
    file, it will read the data which was just written. Of course, this
    assumes that you have write permission on the file and don't mind
    modifying it (and, if you *don't* use append mode, overwriting it).

    Also, if .../fd/0 is a pipe (named or otherwise), opening it for write
    will get you the write end of the pipe, while the process' standard input
    has the read end. This is the one case which will usually work as expected.

    Essentially, you can read or write files (pipes, devices, etc). You can't
    read or write to another process' descriptors.

    In the case of a pipe, writing to the pipe itself Does The Right Thing. In
    some other cases, you could write to some other object to get the desired
    result; e.g. if the process' stdin is a pseudo-terminal, writing to the
    corresponding master device would cause the data to appear on the process'
    stdin (but I don't know if that's actually possible with Unix98-style
    ptys).

    In other cases, there's no way to achieve the desired result. E.g. if the
    process' stdin is a physical terminal, the only way to cause the
    device to generate data is by pressing keys on the terminal.
     
    Nobody, Mar 11, 2011
    #9
  10. OT: processes, terminals and file descriptors on *nix (was: Re: attachto process by pid?)

    On 11.03.2011 03:18, Nobody wrote:
    > On Thu, 10 Mar 2011 23:55:51 +0100, Alexander Kapps wrote:
    >
    >>>> I think he wants to attach to another process's stdin/stdout and
    >>>> read/write from/to them.
    >>>> I don't know if this is possible but it would be a great addition for
    >>>> psutil.
    >>>
    >>> It's not even a meaningful concept, let alone possible.

    >>
    >> Unless I misunderstand something,

    >
    > You do ...


    Many thanks for the correction and lesson (to Grand Edwards too)!

    I still try to digest your explanations. I thought, that processes
    just do something like dup()'ing the file descriptors of their
    terminal but after some strace experiments, I think that is totally
    wrong.

    I'd like to learn more about this (how processes, their controlling
    terminals and the std file descriptors relate)

    Do you know any links to deeper material (tried Google but what I've
    found is to shallow)
     
    Alexander Kapps, Mar 11, 2011
    #10
  11. Danny Shevitz

    Nobody Guest

    Re: OT: processes, terminals and file descriptors on *nix (was: Re: attach to process by pid?)

    On Sat, 12 Mar 2011 00:49:08 +0100, Alexander Kapps wrote:

    > I still try to digest your explanations. I thought, that processes
    > just do something like dup()'ing the file descriptors of their
    > terminal but after some strace experiments, I think that is totally
    > wrong.


    Actually, the way that descriptors are inherited by a fork()ed process is
    akin to dup(). In particular, any descriptors which refer to a
    random-access stream (anything which supports lseek(), i.e. a file or
    block device) share a single file position, so lseek()ing on a descriptor
    will affect the file position for any copies of that stream created by
    dup(), dup2() or fork(); the only way to get a stream with its own
    position is to open() the file (etc) again. Likewise for the file
    status flags (O_APPEND, O_NONBLOCK, etc). However, a "cloned" descriptor
    gets its own copy of the file descriptor flags (i.e. the FD_CLOEXEC flag).

    open()ing the /proc/<pid>/fd/<n> pseudo-files is a bit of a hack, and
    Linux-specific. The behaviour is a cross between the fork/dup behaviour
    and a separate open() operation. Opening a descriptor which refers to a
    pipe opens the "correct" end based upon the mode (read or write), as with
    a normal open(), but the resulting descriptor shares its file position and
    status flags, as with fork/dup.

    > I'd like to learn more about this (how processes, their controlling
    > terminals and the std file descriptors relate)


    There's nothing special about the standard descriptors. A child process
    inherits all of its parent's descriptors. If the parent has closed any of
    its standard descriptors, they'll still be closed in the child
    (one exception: Linux will force these descriptors to be open when
    executing a setuid executable to avoid potential security issues).

    Also, the controlling terminal is unrelated to the standard descriptors.
    Upon login, a terminal will typically be assigned as both the controlling
    terminal and all three standard descriptors, but they may diverge after
    that. E.g. if you start a pipeline ("foo | bar | baz") from the shell,
    some of the standard descriptors will be replaced by pipes, but the
    controlling terminal will be unaffected. The controlling terminal relates
    primarily to signals (Ctrl-C, Ctrl-Z, etc) and job control.

    > Do you know any links to deeper material (tried Google but what I've
    > found is to shallow)


    I don't have any links. If you want to understand the core Unix API, the
    best reference I know of is Stevens ("Advanced Programming in the Unix
    Environment", by W. Richard Stevens). Unfortunately, it's not cheap.

    In spite of the title, it doesn't assume any prior Unix knowledge; the
    "Advanced" mainly refers to the fact that it's the opposite of the "Learn
    X in Five Minutes" books, i.e. it's thorough. That's how it comes to >700
    pages while only covering the core API (files, processes, and terminals;
    no sockets, no X, no I18N, ...).
     
    Nobody, Mar 13, 2011
    #11
  12. Re: OT: processes, terminals and file descriptors on *nix

    On 13.03.2011 01:50, Nobody wrote:

    > I don't have any links. If you want to understand the core Unix API, the
    > best reference I know of is Stevens ("Advanced Programming in the Unix
    > Environment", by W. Richard Stevens). Unfortunately, it's not cheap.
    >
    > In spite of the title, it doesn't assume any prior Unix knowledge; the
    > "Advanced" mainly refers to the fact that it's the opposite of the "Learn
    > X in Five Minutes" books, i.e. it's thorough. That's how it comes to>700
    > pages while only covering the core API (files, processes, and terminals;
    > no sockets, no X, no I18N, ...).
    >


    Thanks, Nobody and Dan. I'll have a look at the book.
     
    Alexander Kapps, Mar 16, 2011
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    677
  2. Warren Tang
    Replies:
    1
    Views:
    564
    Warren Tang
    Sep 17, 2008
  3. James Mills

    Re: attach to process by pid?

    James Mills, Mar 9, 2011, in forum: Python
    Replies:
    3
    Views:
    434
    bobicanprogram
    Mar 10, 2011
  4. Miki Tebeka

    Re: attach to process by pid?

    Miki Tebeka, Mar 10, 2011, in forum: Python
    Replies:
    2
    Views:
    782
    Grant Edwards
    Mar 12, 2011
  5. P.S.
    Replies:
    0
    Views:
    341
Loading...

Share This Page