l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2004 Aug 27 23:28

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Identifying the directory that contains the currentlyrunning executable?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Identifying the directory that contains the currentlyrunning executable?



On Fri 27 Aug 04, 11:21 AM, ME <dugan@passwall.com> said:
> Ken Bloom said:
> > I guess that solves the C program problem, because I can use getpid()
> > to fill in the blank, and readlink(2) to find the elf executable.
> >
> > That is one wierd symlink. ME wrote in May
> > (http://www.lugod.org/mailinglists/archives/vox-tech/2004-05/msg00247.html)
> > about deleting the executable file, then recovering it from
> > /proc/$PID/exe, so I had assumed it wasn't a symlink. Looking at it
> > harder, symlinks can't usually point to deleted files [1], but this one
> > can! You can recover the exe with cat, but not with cp. Really wierd.
> 
> Well, the /proc filesystem is not a "normal" filesystem, but is more like
> a kind of collection of data stored in memory and "pointers" to other
> data.
> ("Normal" meaning it is not used so much to create files on a disk as we
> think files exists on disks.)
> 
> I think that the behavior you see when accessing the symlink is one of two
> properties or a combination of two properties:
> 1) A file is not actually deleted until all link to the file are destroyed
> (not talking symlinks) and all processes that have opened that file, close
> the file. (The file may not be listed as available for opening if all the
> links to it are gone, but I do not think the file space is freed by the
> filesystem until the last process with the file open closes it-- could be
> wrong here.)
> 2) The file that is loaded into memory can effectively be written fromm
> memory back out to a file. The thing that looks like a symlink in proc may
> not actually be a conventional symlink.
> 
> I have not looked at proc in detail enough as of late to see how much each
> of these play a role in grabbing copies of deleted applications from proc
> if they are still running on the system.

from fs/proc/base.c, it appears that spin locks are used to make sure that
/proc/# (including /proc/#/exe) isn't unlinked until after the attach count
for the process drops to zero.  note that i said "attach count for a process
drops to zero", and not, "when the disk file is unlinked".

the reason is to avoid a race condition.  if detach_pid(A) is called before
/proc/A/ is cleared from the dcache, it's possible for another process to be
created that reuses pid A.  If this happens, exe is wrong, maps is wrong,
stat is wrong, etc.  classic race condition.

to the eyes of filesystem, it is a symlink, but as ME points out, it's
resident in memory, not disk.  access of /proc files is governed by an
interface determined by the author of that piece of kernel code.

i'm not sure why cp can't be used to make a new copy of the executable when
cat can.  when it comes down to it, cat and cp are the same program: they
open, they read, they write, and they close.  so i guess i concur -- it IS
wierd.  :)

pete

ps- if someone wants to file a bug report, the word "synchroneous" is
incorrectly spelled in the comments of base.c (as of linux 2.6.7).  :)

-- 
Make everything as simple as possible, but no simpler. -- Albert Einstein
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.