Let's say /usr/local/bin/ruby is running in the background, and then we overwrite ruby with a different version, or even delete ruby.

What will happen to those running ruby processes?


It depends on exactly how the executable is updated. If the same file is opened and parts of it are changed, bad things will happen. If it is removed, the file is removed from the directory structure of the filesystem, but not actually unlinked (i.e., deleted) until the last process that has it open has executed it exits. So if the executable is removed and a new one with the same name written in its place, the old one should continue to work ok.

  • "If the same file is opened and parts of it are changed" does not equal to "if the executable is removed and a new one with the same name written in its place" ?? Did you mean mv new file to old file is bad but rm old file then cp new file to old file location is ok?
    – jean
    Mar 31 '18 at 1:23

They'll keep on going. Maybe crash horribly if they try and access themselves and receive something utterly wrong. I wouldn't do it unless I had to :)

  • Yep. I manually update software all the time while scripts are running.
    – John T
    Jan 11 '10 at 18:18
  • 1
    For scripts it is important to have actual recent intrpreters which work with the initially opened file descriptor. In this case it is fine as long as you replace the file and not alter it. For binaries typically they work on the intially mapped FD so its no problem (unless you modify the files). But there might be applications which open the file-name for inspection and that might be risky (I cannot give any negative example however). Most linux distributions/package managers work under the asumption that replacing binaries and libraries (for limited time) is fine.
    – eckes
    Aug 21 '17 at 18:14

What will happen to those running ruby processes?

  1. make a copy of /usr/local/bin/ruby
  2. [if it's not running, run /usr/local/bin/ruby ]
  3. try: rm /usr/local/bin/ruby
  4. and see for yourself :)

It is my understanding that the Linux kernel has a component called the loader that opens the executable file itself, containing the image, during the loading/linking process, and once done with linking to libraries, etc., the loader closes the file. Thus, this process happens and is complete by the time the kernel actually launches the process.

I'm not sure if the original executable on disk needs to be referenced if the executable later tries to import external libraries.

I would say, and it's been my experience that, if you delete the executable on disk, the executable loaded in memory isn't affected. Likewise, if the executable file is replaced with a newer versions, currently executing ones aren't "automatically" updated unless they are halted and relaunched.

I had issues with a RAID controller that caused the entire disk that the root directory and other partitions was mounted on to suddenly act as though it was disconnected. Couldn't load new programs, but ones in memory were working fine, until they needed files from the disk.

  • That doesn't sound very efficient. I think Windows would memory-map it instead, so pages are loaded on demand.
    – sashoalm
    May 9 '14 at 14:24

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.