I’m surprised it doesn’t mention that
/proc/selfautomagically points to the directory of the current process. So if you’re writing a program, you can just look there for information about itselfI’m aware of /proc but usually use lsof to find open fd’s for a process.
Is one better than the other?
lsofjust reads from/procand gives you formatted outputhttps://github.com/lsof-org/lsof/blob/master/lib/dialects/linux/dproc.c#L297
I love *nix’s commitment to the bit on the core abstractions.
I seem to recall in an Operating Systems class we wrote a kernel module and communicated with it through the proc interface?
I may have been through “SysFS” as well? In
/sys/classyou can setup char dev IO with a kernel module (and more). Very helpful for userspace <-> kernel communication (like DMA drivers for userspace applications)Hmm yeah maybe it was /sys, it’s been so long I can’t remember.
I seem to recall echoing into a file to set some value which we then checked the value of in the kernel module code. It was just a hello world type of thing for a college class.
Did you know openBSD does not have this folder? I think the BSD’s do not use /proc. I do not know why though.
Okay, this is legitimately cool as heck. This finally helps me wrap my head around the “everything is a file” concept in Linux. Of course it can just copy the executable to memory for later reference. That’s how the system would not completely have a meltdown when you do live updates.
Excellent share!
It’s a bit more interesting than that…
Linux, unlike Windows, will let you delete a file that is actively in use. It removes the reference on the file system but the contents of the file won’t be deleted until all file pointers to it close. In fact it will still be seen as taking up disk space until it’s garbage collected (deleting a large file that’s in use can be frustrating).
So the file is actually still available to that running process. If you replace it with a new executable and run that then you get the new version.
I am saving this, both for the post AND for the comments.
Damn, I really could have made a lot of use of this over the last 20+ years… Thanks for sharing!
We need the whole set of these in one post
Julia Evans has such great and accessible content, they’re awesome
they are a youtuber?
Better, they make zines! https://jvns.ca/
thanks, it’s got really hard nowdays to find quality content.
This is awesome, and I really no no idea about this!
I no no idea you liked this, nice
d’oh! That’s what I get for trying to type quickly.
That’s ok, sometimes I to to type quickly too
I know what a symlink is, but what is a magic symlink?
A symlink that has been blessed by Richard Stallman.
If you delete a file that’s still open by the app, the link in proc will still exist and you can copy the file back out of proc.
Does that not make them a hard link (pointing to a filesystem node) instead of a symlink (pointing to another filename)?
No, you can’t have a hard link cross filesystems and proc is its own fs type.
Ah - it has its own special magical file system type, that’s the secret sauce. Neat!
/dev and /sys are the other two special ones
Remember the old days before /dev was its own virtual filesystem?
It still is! If you try and boot a kernel with nothing in /dev, you won’t get most of the kernel boot messages since /dev/console doesn’t exist. You need a basic set of device nodes in /dev before udev is started.
If you’re going to rsync a system to new hardware and exclude /dev /proc /sys, it’s better to setup a new mount of your / to a different directory and sync off that, so you get the underlying stuff without the cruft.
Subscribe.
Great tips! Although if i may 🤓 just a little for the top right, it works because what you deleted isn’t the binary, it’s the pointer that points to the binary’s location. The data is still exactly as it was before “deletion”; the symlink is simply a copy of the original pointer’s info; and I’m speculating that the existence of any pointer prevents the system from recycling those addressed bits.
it merely deletes the inode from the directory instead of overwriting the actual data on the disk
Do you know how to build portable executables?
configure --prefix=/proc/self/pwdIt even works in .so files and libtool.
I would generally just set the RPATH to
$ORIGINin the ELF fileMay I have the explanation?
The executable will search for .so files not inside predefined paths like /usr/lib but inside it’s current directory. You may theoretically put
.as an argument toconfigure, but it converts that into an absolute path, snd libtool and linker fail when encountering relative paths inside shared library dependencies.
How would this differ from
--prefix=$(pwd)?--prefix=$(pwd)is resolved at compile time. If you move your compiled .so files to a different directory, they stop working.I see what you mean, very clever solution if a program is using the configure prefix by compiling it into the binary.
That can’t be very common though is it? Usually the configure prefix is just used by
make installto install the binaries into the prefix. If the compiled program needs to know where it is installed it can readargv[0].Have you seen this used somewhere?
I am using this myself in Android app, where you can write files only inside
/data/data/your.app.id/So naturally, if you want to publish a different app,
your.app.idwill be different, so you need to recompile all your Linux tools that you bundle inside your app.If you are not running your Linux tools on Android, you’d probably be better off using Docker or a chroot.
