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?

  • 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 2:31
  • 2
    It's similar to how you can delete the hard disk while running the OS. – jkd Jun 16 '15 at 4:12
  • releated: stackoverflow.com/questions/3356483/… – DarioP Jun 17 '15 at 10:51
54

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.

  • 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 2: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 8: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
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.

  • 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. – immibis 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. ;)

  • +1 for "the actual iddle is why you can't do such and similar things in Windows" – arielf Jun 19 '15 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.