25

screenshot

How does apt-get remove xterm go through? And after it's been uninstalled, xterm doesn't close and continues to function normally.

Is the xterm process cached in RAM whilst it is running?

Volker Siegel
  • 13,315
Huey
  • 799
  • 6
    To be exact, It's not really uninstalling itself - apt-get is uninstalling xterm, and has no idea that it somehow depends on an xterm process - so it's about "Why can xterm be uninstalled while running?". Nice question. – Volker Siegel Jun 16 '15 at 02:31
  • 2
    It's similar to how you can delete the hard disk while running the OS. – jkd Jun 16 '15 at 04:12
  • releated: http://stackoverflow.com/questions/3356483/is-it-safe-to-recompile-an-executable-while-its-running – DarioP Jun 17 '15 at 10:51

3 Answers3

53

Not quite. The file is already open by the program. Deleting the file ( and then replacing it with another version ) does not affect the running program because the original file is held open ( though without a name on disk to open it again ) until the program is done with it. Only when all handles to the file are closed are its data blocks on disk released. Until then the open file can be read and written just like normal -- the only change is that nobody else can open it since its name has been removed.

While parts of the program may have already been read into ram when it is deleted, they may still be discarded and re-read later, or new parts of the program that had not previously been executed can still be loaded from the deleted file.

psusi
  • 38,171
  • 4
    This is the actual reason....this is also the reason why rm -rf / works..... – heemayl Jun 15 '15 at 14:45
  • 6
    If you wanna use the word "works" to describe successfully screwing everything totally up. ;) Interestingly, rm -rf / won't work if you try to run it a second time immediately afterwards ;) – thomasrutter Jun 16 '15 at 02:38
  • 1
    I've often seen "/some/file/name (deleted)" in lsof output, and I know that is what a 'zombie' file looks like... but is there any way of saving the contents of such a file from disappearing when the last file handle dies? – Kilian Foth Jun 16 '15 at 08:34
  • 1
    @KilianFoth, if you can find a process that still has the file open, then you can copy it from /proc/$PID/fd/$ID to another file, but I can't seem to find a way to recover the file in place as all attempts at hard linking the file fail. – psusi Jun 16 '15 at 12:48
  • 3
    @KilianFoth If there is a file handle, then root might be able to create a name for it (and thus prevent deletion) by using the linkat system call. But executables and libraries are memory mapped, which doesn't require a file handle. I don't know of any way to get a handle on a file which only exists because it is memory mapped. Though executables can be accessed through /proc while they are running, so it's only libraries and other memory mapped files which might be beyond recovery. If you want more details about that, you should ask it as a separate question. – kasperd Jun 16 '15 at 18:02
  • So, does that mean if we delete the file in some other way (not the conventional way which deletes only the inode and not the data), in which the data is also re-written by '0's then the process (console) wil stop working.. – Haris Jun 16 '15 at 19:50
  • @kasperd, that's what I meant in my previous comment about attempts to hard link it fail... linkat gives -EXDEV. I don't see why, but it does. – psusi Jun 16 '15 at 23:00
  • @haris I don't think the kernel would allow you to write to the executable while it is running. – kasperd Jun 17 '15 at 06:13
  • @psusi That's interesting. I would not expect that if the new name you tried to give it is indeed on the same partition as the deleted one. – kasperd Jun 17 '15 at 06:14
  • @thomasrutter no actually, rm -rf / doesn't work and hasn't for many years. See the 2nd line in the Description section of the POSIX specification. That's why GNU rm has the --no-preserve-root option. By itself, /bin/rm -rf / is completely harmless. – terdon Jun 17 '15 at 11:25
  • @terdon you probably meant to address that to heemayl, I was just making silly jokes about his comment – thomasrutter Jun 17 '15 at 11:32
8

Is the xterm process cached in RAM whilst it is running?

Exactly. It's similar to the process that allows you to install updates to things while they're running without them crashing. And also why you have to restart services after you update them. Once something is running, its binary is in memory.

If it depends on other files (that aren't in a held "open" state) that are removed or replaced, that might cause issues but for something as discrete as xterm, that isn't an issue.

Oli
  • 299,936
  • 6
    Not quite.. parts of the program are read into memory only when needed, and may be discarded at any time to free up memory for other uses, and so will need to be read in again later ( when the program tries to access those parts again ). – psusi Jun 15 '15 at 14:21
  • 17
    It's not necessarily in RAM. But files aren't actually deleted until they aren't open, including the xterm executable. – Stack Exchange Broke The Law Jun 15 '15 at 14:40
  • @immibis, hence, my answer ;) – psusi Jun 15 '15 at 15:41
2

It is in fact a feature of how computers work: When a program is invoked it is indeed loaded into the memory and it works from there.

A file actually works in the same way. To avoid problems many files in UNIX-ish systems create locks.

The actual riddle is why you can't do such and similar things in Windows.

This feature is actually what allows you to update the whole system, including the programs that are active in your system. ;)

runlevel0
  • 372