Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I started a long running background-process (dd with /dev/urandom) in my ssh console. Later I had to disconnect. When I logged in, again (this time directly, without ssh), the process still seemed to to run.

I am not sure what happened - I did not use disown. When I logged in later, the process was not listed in top at first, but after a while it reclaimed a high CPU percentage, as I expected. So I assume dd is still running.

Now, I'd like to see the progress. I use kill -USR1 <pid> but nothing is printed. Is there any way to get the output again?

share|improve this question
    
If using bash you need to set huponexit if you don't want them to continue after disconnect. –  Kyle Brandt Mar 22 '10 at 20:05
    
@Kyle thx for the info ... –  tanascius Mar 22 '10 at 20:46
add comment

4 Answers 4

up vote 4 down vote accepted

Redirecting all outputs (stdout, stdin, stderr) can disassociate a child process with the parent.

You can try attaching to the process with gdb, type 'c' for continue, and watch that console while you hup it from another.

gdb /bin/dd pid

share|improve this answer
    
Thanks for your answer - gdb itself does not display the output :/ But I was able to restore my lost stderr with gdb - see my own answer for details. –  tanascius Mar 22 '10 at 21:04
add comment

Thanks to kmarsh's answer and this threads I was able to redirect my lost output (stderr) to a file:

gdb /bin/dd 2616

(gdb) p creat("/root/dd.stderr",0600)
[Switching to Thread 0x7f651ece56e0 (LWP 2616)]
$1 = 3
(gdb) p dup2(3,2)
$2 = 2
(gdb) p close(3)
$3 = 0
(gdb) q

After running kill -USR1 2616 I can cat my new file:

631820341060 bytes (632 GB) copied, 81603.1 s, 7.7 MB/s
share|improve this answer
    
That's really clever. Good job. –  Bill Weiss Mar 23 '10 at 16:52
add comment

i'm afraid not. but next time - use screen. google for tutorials or start here.

share|improve this answer
add comment

You might be able to see the output by looking in /proc/(pid of your dd/fd/1 or /proc/(pid)/fd/2. Cat that, then hit it with a USR1 and see if you get anything.

share|improve this answer
    
Unfortunately ` ls proc/<pid>/fd/2` says 2 -> /dev/pts/0 (deleted) ... :/ –  tanascius Mar 22 '10 at 20:44
    
Well, that's where your output is going. Bummer. –  Bill Weiss Mar 23 '10 at 16:52
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.