Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 3 down vote favorite

I am running a program fls (from the Sleuth Kit) with option -v for verbose mode. However it takes too long, and the program is still running since yesterday. I guess it will run faster without verbose mode, but I am not sure how long it takes to finish running and whether it is worth to stop and rerun it without verbose. so I wonder if it is possible to turn off verbose mode in the middle of running and resume the running after that? Thanks!

share|improve this question

2 Answers

up vote 3 down vote accepted

As lynxlynxlynx points out, unless the program author makes provisions for it, you cannot change the verbosity while the program is running, but you can keep it from printing to a terminal in case that is a bottle neck.

To do this, close the terminal after telling the shell not to send a SIGHUP. Most shells will send a SIGHUP to any jobs that are still running when you try to exit. You can tell the shell not to do this. There are various ways to do this; the most straightforward is probably with disown.

If you haven't yet, suspend the job with ctrl+z, then make it run again in the background with bg, then run disown. The shell no longer tracks this process as a job, so it will not send a SIGHUP when exiting.

If you have already put the program in the backgound, then if there are any other background jobs that were started after it, you'll need the jobspec of the program you're interested in to use as a parameter to pass to bg and disown.

share|improve this answer
Thanks! (1) How can I find the jobspec of the program if it is running in background? (2) After ctrl+Z, the program is suspended and its job id is 1. Next I type bg 1, and then the program resumes running and outputs again in the terminal. I don't know how I can type "disown 1" again when it is outputing to the terminal. Ctrl+Z doesn't work for programs running in background. – Tim Aug 7 '12 at 13:15
@Tim I haven't found an official resource saying what it is, but from experimentation, the field on the right (that shows the command) works in bash and zsh, but not in ash. Sometimes the pid also works. – Shawn J. Goff Aug 7 '12 at 15:20
up vote 5 down vote

Maybe there is a hack that would allow to change the job's output file descriptor to /dev/null, but I don't know it. In any case, the program would still be writting all those lines, they would just be discarded. This would therefore only help if the terminal display is the bottleneck, not the message generation.

share|improve this answer
Thanks! (1) It actually outputs to stderr instead of stdout. I am also curious to know how to change the output to /dev/null on the fly. (2) How can I tell if the terminal display or the message generation is the bottleneck to the running speed of the program? – Tim Aug 7 '12 at 12:10
Look at Shawn's answer. As for (2), you'd have to do some coding to check. Lots and lots of output can really be a burden from my experience with one opensource project (we disabled it to gain a boost in the android port). – lynxlynxlynx Aug 7 '12 at 13:06

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.