Is there any way to dissociate a process from its on-disk binary? In
other words, I want to start 'foo_daemon', then unmount the filesystem
it started from. It seems to me this would be reasonably accomplished
by loading the binary completely into memory first ro eliminate the
dependence.
Is this possible, or planned? Are there intractable problems with it
that I don't see?
Eric Buddington
You could always copy the process to a RAM filesystem like tmpfs
or a ramdisk.
On Wed, Apr 24, 2002 at 10:47:14PM -0400, Eric Buddington wrote:
> Is there any way to dissociate a process from its on-disk binary? In
> other words, I want to start 'foo_daemon', then unmount the filesystem
> it started from. It seems to me this would be reasonably accomplished
> by loading the binary completely into memory first ro eliminate the
> dependence.
>
> Is this possible, or planned? Are there intractable problems with it
> that I don't see?
>
> Eric Buddington
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-- James Cassidy (QFire)
On Wed, Apr 24, 2002 at 10:47:14PM -0400, Eric Buddington wrote:
> Is there any way to dissociate a process from its on-disk binary? In
> other words, I want to start 'foo_daemon', then unmount the filesystem
> it started from. It seems to me this would be reasonably accomplished
> by loading the binary completely into memory first ro eliminate the
> dependence.
>
> Is this possible, or planned? Are there intractable problems with it
> that I don't see?
as i understand it this precludes you from using shared libs as they are
mmap()'d on startup...
other than that the running daemon will cause the fs to be
un-umountable.
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
Doesn't mlockall() do this?
man mlockall
/Johan
----- Original Message -----
From: "john slee" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: den 25 april 2002 10:52
Subject: Re: Dissociating process from bin's filesystem
> On Wed, Apr 24, 2002 at 10:47:14PM -0400, Eric Buddington wrote:
> > Is there any way to dissociate a process from its on-disk binary? In
> > other words, I want to start 'foo_daemon', then unmount the filesystem
> > it started from. It seems to me this would be reasonably accomplished
> > by loading the binary completely into memory first ro eliminate the
> > dependence.
> >
> > Is this possible, or planned? Are there intractable problems with it
> > that I don't see?
>
> as i understand it this precludes you from using shared libs as they are
> mmap()'d on startup...
>
> other than that the running daemon will cause the fs to be
> un-umountable.
>
> j.
>
> --
> R N G G "Well, there it goes again... And we just sit
> I G G G here without opposable thumbs." -- gary larson
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I'm think this is not possible at the moment.
The file of the executing process is in use as the backing store for
one or more live virtual memory areas, so changing it could
corrupt the processes using those areas. Hence you can't umount.
Now the Mach kernel has a MAP_COPY flag to the mmap system call
which would do what you want, but this is mucho complex/messy,
so don't hold your breath for a linux implementation.
A related note on shared libraries is you don't get the
"text file busy" message if you update them while they're in use,
like you do for executable files. The reason is MAP_DENYWRITE
is ignored for security reasons. I think Eric Biederman has
a workaround though?
So in summary if you want a process to run independently of
a filesystem, make it static and run it from a ramdisk.
Padraig.
Eric Buddington wrote:
> Is there any way to dissociate a process from its on-disk binary? In
> other words, I want to start 'foo_daemon', then unmount the filesystem
> it started from. It seems to me this would be reasonably accomplished
> by loading the binary completely into memory first ro eliminate the
> dependence.
>
> Is this possible, or planned? Are there intractable problems with it
> that I don't see?
>
> Eric Buddington
On Wednesday 24 April 2002 10:47 pm, Eric Buddington wrote:
> Is there any way to dissociate a process from its on-disk binary?
Sure. Fire up an instance of ramfs, copy the file there (and its associated
libraries), chroot and exec the copy on ramfs. Sort of like initrd in
reverse. :)
You could also try to extensively rewrite the kernel to completely disable
paging, but I wouldn't recommend it.
Rob
Rob Landley wrote:
>
> On Wednesday 24 April 2002 10:47 pm, Eric Buddington wrote:
> > Is there any way to dissociate a process from its on-disk binary?
>
> Sure. Fire up an instance of ramfs, copy the file there (and its associated
> libraries), chroot and exec the copy on ramfs. Sort of like initrd in
> reverse. :)
If you're writing the binary in question, you could use mlockall() which ensures
that you won't need to page in bits of the binary from disk. I don't know if
the filesystem considers this totally dissociated though, but it might be good
enough for what you want.
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: [email protected]
Padraig Brady <[email protected]> writes:
> I'm think this is not possible at the moment.
>
> The file of the executing process is in use as the backing store for
> one or more live virtual memory areas, so changing it could
> corrupt the processes using those areas. Hence you can't umount.
>
> Now the Mach kernel has a MAP_COPY flag to the mmap system call
> which would do what you want, but this is mucho complex/messy,
> so don't hold your breath for a linux implementation.
>
> A related note on shared libraries is you don't get the
> "text file busy" message if you update them while they're in use,
> like you do for executable files. The reason is MAP_DENYWRITE
> is ignored for security reasons. I think Eric Biederman has
> a workaround though?
I played with it but could find nothing better than.
chmod a-w file
And it wasn't terribly important personally so I dropped it.
Eric