Redirecting stdout of running program - Linux

This is a discussion on Redirecting stdout of running program - Linux ; Hi all when I have a program running for too long and I have to disconnect the shell, I do the usual ctrl-Z bg 1 disown %1 dance, so that I can disconnect the shell and keep it running. However ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: Redirecting stdout of running program

  1. Redirecting stdout of running program

    Hi all
    when I have a program running for too long and I have to disconnect the
    shell, I do the usual
    ctrl-Z
    bg 1
    disown %1
    dance, so that I can disconnect the shell and keep it running. However
    this makes me lose any stdout the program was generating.

    I would need to redirect the stdout to a file before disowning it. I
    tried to go in the /proc/$pid/fd directory and I tried to change the
    symbolic link from "1" (the stdout, usually pointing to
    /dev/pts/somenumber) make it point to some other file on disk, doing
    ln -sf /somefile 1
    but it gives to me:
    ln: cannot remove `1': Operation not permitted
    even when trying as root.

    Is there any way to redirect the stdout of a running program?

    (please don't suggest me to redirect output in advance or to use nohup:
    this is obvious but I am speaking for the case when the program runs
    much longer than it was expected)

    Thank you

  2. Re: Redirecting stdout of running program

    On Aug 25, 8:21*am, linuxnewbie1234
    wrote:

    > Is there any way to redirect the stdout of a running program?
    >
    > (please don't suggest me to redirect output in advance or to use nohup:
    > this is obvious but I am speaking for the case when the program runs
    > much longer than it was expected)


    No, and for fairly good reasons. The program may check early in its
    run whether it's writing to a terminal or a file, and may fail if
    operations specific to that type later fail.

    DS

  3. Re: Redirecting stdout of running program

    linuxnewbie1234 writes:

    > Hi all
    > when I have a program running for too long and I have to disconnect
    > the shell, I do the usual
    > ctrl-Z
    > bg 1
    > disown %1
    > dance, so that I can disconnect the shell and keep it running. However
    > this makes me lose any stdout the program was generating.
    >
    > I would need to redirect the stdout to a file before disowning it. I
    > tried to go in the /proc/$pid/fd directory and I tried to change the
    > symbolic link from "1" (the stdout, usually pointing to
    > /dev/pts/somenumber) make it point to some other file on disk, doing
    > ln -sf /somefile 1
    > but it gives to me:
    > ln: cannot remove `1': Operation not permitted
    > even when trying as root.
    >
    > Is there any way to redirect the stdout of a running program?


    You could attach a debugger and do anything you like. Short of that,
    I don't think there's a way.

    --
    Måns Rullgård
    mans@mansr.com

  4. Re: Redirecting stdout of running program

    linuxnewbie wrote:

    > when I have a program running for too long and I have to disconnect the
    > shell, I do the usual
    > ctrl-Z
    > bg 1
    > disown %1
    > dance, so that I can disconnect the shell and keep it running. However this
    > makes me lose any stdout the program was generating.
    >
    > Is there any way to redirect the stdout of a running program?


    Why not run your program under screen(1), then you can detach the program
    from your terminal and pick it up later.

    --
    Huibert
    "Okay... really not something I needed to see." --Raven

  5. Re: Redirecting stdout of running program

    On Mon, 25 Aug 2008 18:52:59 +0200 Huibert Bol wrote:

    | linuxnewbie wrote:
    |
    |> when I have a program running for too long and I have to disconnect the
    |> shell, I do the usual
    |> ctrl-Z
    |> bg 1
    |> disown %1
    |> dance, so that I can disconnect the shell and keep it running. However this
    |> makes me lose any stdout the program was generating.
    |>
    |> Is there any way to redirect the stdout of a running program?
    |
    | Why not run your program under screen(1), then you can detach the program
    | from your terminal and pick it up later.

    I have done debugging of programs in the past that were attempting to write
    to a closed or dead-end descriptor, and ignoring the errors, by running it
    under strace. Maybe what I need to do is write a program specifically to
    capture the output of other programs that uses ptrace() to see the writes
    and collect what is written and send it where desired. Of course this would
    not work if the program decides to quit doing writes because it gets errors
    doing so, but otherwise keeps on running.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  6. Re: Redirecting stdout of running program

    Måns Rullgård wrote:
    > You could attach a debugger and do anything you like. Short of that,
    > I don't think there's a way.


    Interesting...
    I still don't know how to use gdb or other Linux debuggers.
    Is there a general approach for doing what I asked with gdb against a
    generic (= unknown) running program?

    Thank you

  7. Re: Redirecting stdout of running program

    David Schwartz wrote:
    > No, and for fairly good reasons. The program may check early in its
    > run whether it's writing to a terminal or a file, and may fail if
    > operations specific to that type later fail.


    What is it that is possible with a terminal (output!) but not possible
    with a file?

  8. Re: Redirecting stdout of running program

    linuxnewbie1234 writes:

    > David Schwartz wrote:
    >> No, and for fairly good reasons. The program may check early in its
    >> run whether it's writing to a terminal or a file, and may fail if
    >> operations specific to that type later fail.

    >
    > What is it that is possible with a terminal (output!) but not possible
    > with a file?


    Formatting output in the right number of columns for the terminal (as
    ls does) comes to mind immediately.

  9. Re: Redirecting stdout of running program

    linuxnewbie wrote:

    > Måns Rullgård wrote:
    >> You could attach a debugger and do anything you like. Short of that,
    >> I don't think there's a way.

    >
    > Interesting...
    > I still don't know how to use gdb or other Linux debuggers.
    > Is there a general approach for doing what I asked with gdb against a generic
    > (= unknown) running program?


    Assuming all you want to do is redirect standard output:

    1. Determine the process id of the program in question.

    2. Fire up GDB.

    3. Enter 'attach /pid/'

    4. Close standard output: 'call close(1)'

    5. Reopen standard output to a new destination: 'call creat("file", 0600)'

    6. Enter 'detach', then 'quit'


    I think it's probably a lot easier to redirect the output in the first place,
    it's not as if you can't sneak a peek in that file from time to time.

    --
    Huibert
    "Okay... really not something I needed to see." --Raven

  10. Re: Redirecting stdout of running program

    linuxnewbie1234 writes:

    > David Schwartz wrote:
    >> No, and for fairly good reasons. The program may check early in its
    >> run whether it's writing to a terminal or a file, and may fail if
    >> operations specific to that type later fail.

    >
    > What is it that is possible with a terminal (output!) but not possible
    > with a file?


    All the termios calls, for starters.

    --
    Måns Rullgård
    mans@mansr.com

  11. Re: Redirecting stdout of running program

    On Aug 26, 2:23*am, linuxnewbie1234
    wrote:
    > David Schwartz wrote:
    > > No, and for fairly good reasons. The program may check early in its
    > > run whether it's writing to a terminal or a file, and may fail if
    > > operations specific to that type later fail.

    >
    > What is it that is possible with a terminal (output!) but not possible
    > with a file?


    Getting the number of rows and columns, clearing the screen, changing
    the color, bold, underlining, and many, many of other things.

    DS

  12. Re: Redirecting stdout of running program

    On Aug 26, 9:51*am, Huibert Bol wrote:

    > Assuming all you want to do is redirect standard output:
    >
    > * 1. Determine the process id of the program in question.
    >
    > * 2. Fire up GDB.
    >
    > * 3. Enter 'attach /pid/'
    >
    > * 4. Close standard output: 'call close(1)'
    >
    > * 5. Reopen standard output to a new destination: 'call creat("file", 0600)'
    >
    > * 6. Enter 'detach', then 'quit'


    This should work, and you can pretty easily create a script to do this
    automatically. Just understand that you will have to test this with
    every program you want to use it with -- and be prepared for
    unpredictable results.

    If the program ever does any terminal-specific operation, it will fail
    with 'ENOTTY', which the application may consider a fatal error. Or it
    may do just about anything else. It's not supposed to be possible for
    terminals to spontaneously turn into non-terminals.

    Of course, it might work just fine for the things you care about most.

    DS

  13. Re: Redirecting stdout of running program

    linuxnewbie1234 wrote:
    > David Schwartz wrote:
    >> No, and for fairly good reasons. The program may check early in its
    >> run whether it's writing to a terminal or a file, and may fail if
    >> operations specific to that type later fail.

    >
    > What is it that is possible with a terminal (output!) but not possible
    > with a file?


    Me too:

    Buffering:
    if you output to a terminal, you'd get line buffering (buffers flushed
    when a linefeed is output), but if you output to a file, you'd get ...
    ah ... well ... "buffer buffering" (buffers flushed when they are full).

    Not that it's impossible to do "buffer buffering" with a terminal, but
    you won't see any output until some 4k or such of output has been
    generated, or line buffering with files (you'd get more write() calls
    than needed, as you wouldn't notice anyway).
    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html

  14. Re: Redirecting stdout of running program

    Huibert Bol wrote:
    > 4. Close standard output: 'call close(1)'
    > 5. Reopen standard output to a new destination: 'call creat("file", 0600)'
    > .....


    Excellent! Thanks alot, I have scripted this.

    Only one problem: I would prefer to use:

    call open("$2",O_CREAT|O_WRONLY|O_APPEND)

    so to append to file. However gdb does not understand the "O_CREAT",
    "O_WRONLY" and "O_APPEND" macro constants. Is there any way to instruct
    gdb to recognize them?

    Thank you

  15. Re: Redirecting stdout of running program

    linuxnewbie1234 pisze:
    > Only one problem: I would prefer to use:
    >
    > call open("$2",O_CREAT|O_WRONLY|O_APPEND)
    >
    > so to append to file. However gdb does not understand the "O_CREAT",
    > "O_WRONLY" and "O_APPEND" macro constants. Is there any way to instruct
    > gdb to recognize them?


    Why not write a simple C program that dumps the numerical
    value of "O_CREAT | O_WRONLY | O_APPEND" to the screen and
    use this value inside gdb instead?

    HTH,
    - J.

  16. Re: Redirecting stdout of running program

    Jacek Dziedzic wrote:
    > Why not write a simple C program that dumps the numerical
    > value of "O_CREAT | O_WRONLY | O_APPEND" to the screen and
    > use this value inside gdb instead?


    I had thought of that, yes. So there is no other way?

  17. Re: Redirecting stdout of running program

    linuxnewbie1234 wrote:
    > Jacek Dziedzic wrote:
    > > Why not write a simple C program that dumps the numerical
    > > value of "O_CREAT | O_WRONLY | O_APPEND" to the screen and
    > > use this value inside gdb instead?


    > I had thought of that, yes. So there is no other way?


    Well, you can look them up in the header files, just as the
    compiler does. On my system they are defined in the file
    /usr/include/bits/fcntl.h (take care, the numbers may be in
    octal).
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ jt@toerring.de
    \__________________________ http://toerring.de

  18. Re: Redirecting stdout of running program

    In article ,
    Huibert Bol wrote:
    > Assuming all you want to do is redirect standard output:
    >
    > 1. Determine the process id of the program in question.
    >
    > 2. Fire up GDB.
    >
    > 3. Enter 'attach /pid/'
    >
    > 4. Close standard output: 'call close(1)'
    >
    > 5. Reopen standard output to a new destination: 'call creat("file", 0600)'
    >
    > 6. Enter 'detach', then 'quit'


    You are assuming that the program has not closed standard input.

    Maybe something like dup2(creat("file",0600),1) would be better.

    --
    --Tim Smith

  19. Re: Redirecting stdout of running program

    In article
    <0f52ea5d-2f27-4f9d-8bf4-fe0cac344999@r15g2000prd.googlegroups.com>,
    David Schwartz wrote:
    > > Is there any way to redirect the stdout of a running program?
    > >
    > > (please don't suggest me to redirect output in advance or to use nohup:
    > > this is obvious but I am speaking for the case when the program runs
    > > much longer than it was expected)

    >
    > No, and for fairly good reasons. The program may check early in its
    > run whether it's writing to a terminal or a file, and may fail if
    > operations specific to that type later fail.


    That isn't a fairly good reason, for a Unix-like system. The Unix
    philosophy includes giving us sharp tools, and leaving it up to us to
    use them without cutting ourselves. Not providing a tool because some
    people might use it in ways that might confuse some programs is not the
    Unix way.

    --
    --Tim Smith

  20. Re: Redirecting stdout of running program

    I would suggest using screen. It creates a terminal you can attach and detach when you want. You can not pipe it into another program, but it still allows you to continue using the program.

    linuxnewbie1234 wrote:

    > Hi all
    > when I have a program running for too long and I have to disconnect the
    > shell, I do the usual
    > ctrl-Z
    > bg 1
    > disown %1
    > dance, so that I can disconnect the shell and keep it running. However
    > this makes me lose any stdout the program was generating.
    >
    > I would need to redirect the stdout to a file before disowning it. I
    > tried to go in the /proc/$pid/fd directory and I tried to change the
    > symbolic link from "1" (the stdout, usually pointing to
    > /dev/pts/somenumber) make it point to some other file on disk, doing
    > ln -sf /somefile 1
    > but it gives to me:
    > ln: cannot remove `1': Operation not permitted
    > even when trying as root.
    >
    > Is there any way to redirect the stdout of a running program?
    >
    > (please don't suggest me to redirect output in advance or to use nohup:
    > this is obvious but I am speaking for the case when the program runs
    > much longer than it was expected)
    >
    > Thank you



+ Reply to Thread