Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

Let's say I stop a process using Ctrl+Z and resume it five hours later using fg. How risky is this with regards to the proper functioning of the process?

For instance, imagine that vim is working on writing a big file to disk, and that I stop it during the write. Will vim happily finish writing the file when I resume it, without any issues? As an extreme situation, what happens if I deleted the file in the meantime? Can I end up corrupting the file system? (Is deleting a file that the stopped vim was writing to even possible, or will the file system drivers prevent me from deleting the file until vim is done writing to it?)

vim is obviously a relatively simple piece of software, being "merely" a text editor. Can I stop and resume complex pieces of software such as apache or X11 without expecting too many issues (other than clients timing out, in the case of Apache)?

share|improve this question
up vote 6 down vote accepted

Essentially, Ctrl-Z is not a dangerous thing to do. You shouldn't be afraid of it.

What exactly will happen depends on what the process is doing. Your examples are good ones to consider.

The first, with vim writing a file... nothing bad will happen. If there's still disk space left when you resume vim, it will finish writing the file. If you kill vim while it's suspended, the file will be truncated with as much data as had been written before it was suspended (as far as you need to be concerned, anyway). If you delete the file while vim is suspended, essentially vim will continue to see the file as long as it needs it. From outside vim, the file will be seen as deleted, but vim will still see it until it finishes writing, and closes it, at which point it will disappear. (If vim tries to then reopen it, it will be gone.) After you're used to that last behavior, you're feel like you're using a silly play toy when Windows locks files.

Your second example could cause problems. If there are other processes interacting with yours, they will all be a bit stuck waiting on this app. So yes, client timeouts will occur, some processes might block indefinitely waiting to read data, etc. But still nothing really "bad" will happen. Nothing that should damage the system, unless there is a bug somewhere. (For example, a poorly written app that can't handle the timeout just gives up and loses all its data... but that's not the fault of the app you suspended.)

Apache would stop serving web pages, obviously. X11 would stop pushing pixels around. But generally when you start it back up again, things that were blocking will resume, and if clients have timed out, if you restart them, they'll work fine again too.

share|improve this answer

Unix is a time sharing operating system, so programs don't get exclusive access to the CPU anyway, they share it with other programs and the operating system itself. When you suspend a program, you're only delaying the time until the next execution period. Depending on the program i.e. if it's time sensitive like network or video playback software, you could get timeouts, but nothing bad happens basically.

As for the second question regarding deletion of a file while the program is still "running", see question "When does rm remove open files?".

share|improve this answer

Basically, it depends on the program. With vim(1) (or with vi(1)) you can even kill it, that you will have the possibility of recovering the file up to the moment of the kill without loosing data, even if the whole system has crashed (look at the vi(1)/vim(1) man page)

In general, stopping a program for five hours can have some lateral effects that can corrupt whatever you are doing.

Suppose the program you have open is a network client (for example a ssh(1) session to another machine) Normally, servers activate a TCP option called SO_KEEPALIVE that allow to maintain the connection alive even if you don't have nothing to say. In this case, it doesn't hurt, as the kernel, having an open TCP connection, makes the KEEPALIVE in behalf of the stopped process (tcp connections are kernel resources, not userland process resources) and you can maintain the process stopped indefinitely.

But what happens if the server is trying to send some data and the client doesn't acknowledge it. Perhaps the application protocol has a timeout to drop a connection if the client doesn't say anything for a long period of time (or the server fills all the buffer of data to the client and cannot block). In that case, you'll get a client trying to use a connection that has dropped time ago (the server went away).

So the answer to this question is: In general no problem, but it depends exactly on what the program stopped needs from its environment (it sleeps, but the world continues to rotate)

share|improve this answer

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.