Removing an executable while it runs

Removing an executable while it runs

[Cyrille Beraud]

Hello,
I would like to remove an executable from the file-system while it is 
running and
get all the blocks back immediately, not after the end of the program.
Is this possible ?
 From what I understand, the inode is not released until the program 
ends. Do all the
file-systems behave the same way ?

Thank you for your help.

Re: Removing an executable while it runs

[Brian Gerst]

Cyrille Beraud wrote:
> 
> Hello,
> I would like to remove an executable from the file-system while it is
> running and
> get all the blocks back immediately, not after the end of the program.
> Is this possible ?
>  From what I understand, the inode is not released until the program
> ends. Do all the
> file-systems behave the same way ?
> 
> Thank you for your help.

It is not possible to reclaim the disk space until the program exits. 
This is because of demand paging of executables.  The file must be kept
around to handle possible future page faults, otherwise the program
would crash if it called code that hadn't been loaded yet or was
discarded due to memory pressure.  This is true of all filesystems.

--

				Brian Gerst

Re: Removing an executable while it runs

[Petr Vandrovec]

On  5 Dec 01 at 11:00, Cyrille Beraud wrote:

> I would like to remove an executable from the file-system while it is 
> running and
> get all the blocks back immediately, not after the end of the program.
> Is this possible ?

No. Binary runs from these blocks. Maybe you can force it to run from
swap by modifying these pages through ptrace interface, but it is
not supported. Just kill the app if you need these blocks.

>  From what I understand, the inode is not released until the program 
> ends. Do all the file-systems behave the same way ?

No. Some will refuse to unlink running app (or another opened file).
Some will unlink it immediately, and app then dies when it needs
page-in something. Some works as POSIX mandates.

                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: Removing an executable while it runs

[Mike Fedyk]

On Wed, Dec 05, 2001 at 05:15:52PM +0000, Petr Vandrovec wrote:
> On  5 Dec 01 at 11:00, Cyrille Beraud wrote:
> 
> > I would like to remove an executable from the file-system while it is 
> > running and
> > get all the blocks back immediately, not after the end of the program.
> > Is this possible ?
> 
> No. Binary runs from these blocks. Maybe you can force it to run from
> swap by modifying these pages through ptrace interface, but it is
> not supported. Just kill the app if you need these blocks.
> 
> >  From what I understand, the inode is not released until the program 
> > ends. Do all the file-systems behave the same way ?
> 
> No. Some will refuse to unlink running app (or another opened file).
> Some will unlink it immediately, and app then dies when it needs
> page-in something. Some works as POSIX mandates.
> 

POSIX behaviour would be in ext[23], reiserfs, xfs, (and probably ffs,
ntfs).  Can someone verify which FSes have what behaviour?

I'd guess that vfat (fat16/28--err, 32), nfs, and hfs would delete
immediately.

mf

Re: Removing an executable while it runs

[Christopher Friesen]

Brian Gerst wrote:
> 
> Cyrille Beraud wrote:
> >
> > Hello,
> > I would like to remove an executable from the file-system while it is
> > running and
> > get all the blocks back immediately, not after the end of the program.
> > Is this possible ?
> >  From what I understand, the inode is not released until the program
> > ends. Do all the
> > file-systems behave the same way ?
> >
> > Thank you for your help.
> 
> It is not possible to reclaim the disk space until the program exits.
> This is because of demand paging of executables.  The file must be kept
> around to handle possible future page faults, otherwise the program
> would crash if it called code that hadn't been loaded yet or was
> discarded due to memory pressure.  This is true of all filesystems.

Couldn't you use mlockall() to ensure that demand paging is not a factor?  Then
you should be able to free up the disk space since the actual application is
guaranteed to be in ram.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: Removing an executable while it runs

[Tim Walberg]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On 12/05/2001 15:00 -0500, Christopher Friesen wrote:
>>	Couldn't you use mlockall() to ensure that demand paging is not a factor?  Then
>>	you should be able to free up the disk space since the actual application is
>>	guaranteed to be in ram.
>>	


mlockall() only locks those pages that are **currently** paged
in, or optionally those that will be paged in in the future.
Unless you have a way to make sure that all pages of the
binary are actually in memory before you call mlockall(),
this gains you nothing.



-- 
twalberg@mindspring.com

[-- Attachment #2: Type: application/pgp-signature, Size: 175 bytes --]

Re: Removing an executable while it runs

[Petr Vandrovec]

On  5 Dec 01 at 11:32, Mike Fedyk wrote:
> > No. Some will refuse to unlink running app (or another opened file).
> > Some will unlink it immediately, and app then dies when it needs
> > page-in something. Some works as POSIX mandates.
> > 
> 
> POSIX behaviour would be in ext[23], reiserfs, xfs, (and probably ffs,
> ntfs).  Can someone verify which FSes have what behaviour?
> 
> I'd guess that vfat (fat16/28--err, 32), nfs, and hfs would delete
> immediately.

ncpfs (and afaik smbfs) will refuse to delete file. For local filesystems
there is no excuse to not support POSIX semantic on unlink if they do not
store data together with filename.
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: Removing an executable while it runs

[Jeff Dike]

twalberg@mindspring.com said:
> mlockall() only locks those pages that are **currently** paged in, or
> optionally those that will be paged in in the future. Unless you have
> a way to make sure that all pages of the binary are actually in memory
> before you call mlockall(), this gains you nothing.

No, mlockall will page in the entire process before returning if you ask it to.

See this snippet in mlock_fixup:

		if (newflags & VM_LOCKED) {
			pages = -pages;
			make_pages_present(start, end);
		}

VM_LOCKED comes in through the mlockall system call.

				Jeff

Re: Removing an executable while it runs

[Eric-Olivier Lamey]

On Wed, Dec 05, 2001 at 07:25, Jeff Dike wrote:
> twalberg@mindspring.com said:
> > mlockall() only locks those pages that are **currently** paged in, or
> > optionally those that will be paged in in the future. Unless you have
> > a way to make sure that all pages of the binary are actually in memory
> > before you call mlockall(), this gains you nothing.
> 
> No, mlockall will page in the entire process before returning if you ask it to.
> 
> See this snippet in mlock_fixup:
> 
> 		if (newflags & VM_LOCKED) {
> 			pages = -pages;
> 			make_pages_present(start, end);
> 		}
> 
> VM_LOCKED comes in through the mlockall system call.
> 
> 				Jeff

  Well, according to the man page, mister Walberg is right. How can I
  force mlockall to page in the entire process ? And if it is possible,
  I guess it won't resolve my problem since it is the filesystem which
  refuses to release the blocks, right ?
  To be more precise, here is my situation: the executable file is
  located on a ramfs filesystem. Once it is started, I would like to get
  the space back so that the RAM can be used. Is there a clean solution ?

  P.S: on behalf of Cyrille (who made the first post), I would like to
  thank you for your answers, it is greatly appreciated.

  P.P.S: is it required to include the people involved in the thread in
  the Cc: field ? I have looked in the mailing list FAQ and have not
  found the reason.

-- 
Eric-Olivier Lamey