Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Using bash, one can pause a process with control-z. However, are there any general circumstances or guidelines to beware of where a process would not behave well with being paused?

My specific scenario was in creating a tar file that was taking longer than expected. I wanted to pause it to put it in the background, but decided not to. My question isn't, of course, specific to tar. Rather, I'm hoping to understand the pausing feature in bash a bit better as well as what would make a process react poorly to being paused.

share|improve this question
up vote 3 down vote accepted

Storage tasks (pvmove, veritas vx-whatever) that rely on atomic copies. It is not good if they get stuck outside of their control. It depends on whether the task just fires off some API and does the rest from kernel space, then it's safe. If it's happening in that *process* in your shell, then really go with screen and keep hands off.

Definitely recommend you to avoid stopping them to background. Commands that use buffers like dd seem to be better off, with the exception of the tape drives mentioned above.

(I once won an additional reboot, less sleep and a lot of paranoia when that happened to me while clearing up other people's mess. obviously: don't try taking shortcuts if you're fixing other peoples shortcuts...)

share|improve this answer

If your process is writing out data, just be aware that timing issues with non-random access devices and buffers may be problematic. I've seen tape drives have issues with this at times.

share|improve this answer
network / firewall sessions may time out and not be restarted because TCP-SYN not being resent. – jippie May 25 '12 at 6:55
The TCP stack would continue sending ACKs that the window is full though, right? – Magellan May 25 '12 at 15:55
Keep alive packets is not part of the TCP nor the IP protocol, at best it is part of the application. So a firewall or a remote client or server may timeout waiting for a packet and drop the socket/connection. – jippie May 25 '12 at 17:08
Not speaking to keepalives, those are obviously Application level. I'm talking about ACKs for the TCP sliding window at the Transport level. – Magellan May 25 '12 at 20:01

And the mundane scenario: doing Ctrl-Z, then forgetting about it and logging off, and losing the process! =)

share|improve this answer

Not really a specific answer to the question, but alternatively, you could attempt to run concurrent jobs using screen. You can thus use the shell concurrently with another program.

share|improve this answer
Yes, screen is always a good way to go. I am not sure how to respond to your name, however. – Wesley May 25 '12 at 5:18
@toiletfreak How is screen an alternative to pausing? Screen runs a job in the background right? But it continues if you detach the screen... – Bernhard May 25 '12 at 5:48

Your Answer


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.