Какие существуют риски при остановке и возобновлении процессов в Linux?

497
haroba

Допустим, я остановил процесс Ctrl+Zи возобновил его через пять часов fg. Насколько это рискованно в отношении правильного функционирования процесса?

Например, представьте, что vimработает над записью большого файла на диск, и я остановил его во время записи. Будет ли vimсчастливо дописать файл, когда я возобновить его, без каких - либо проблем? Как чрезвычайная ситуация, что произойдет, если я удалю файл за это время? Могу ли я в конечном итоге повредить файловую систему? ( vimВозможно ли вообще удалить файл, запись которого остановила запись, или драйверы файловой системы не позволят мне удалить файл, пока vimзапись не будет завершена?)

vimэто, очевидно, относительно простая часть программного обеспечения, являющаяся «просто» текстовым редактором. Могу ли я остановить и возобновить сложные части программного обеспечения, такие как apacheили X11не ожидая слишком много проблем (кроме времени ожидания клиентов, в случае Apache)?

1

3 ответа на вопрос

6
Geoff Gustafson

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.

1
Cristian Ciupitu

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?".

-1
Luis Colorado

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)

Похожие вопросы