I never really considered using proc to solve my problems. I jump to logs and such but honestly, how have I never played with proc?
The hand written effect make these so much easier to digest.
I have some of her paper zines on my desk, warmly recommended.
Might look esoteric at first but if you think we will be using Linux at least on desktop, servers, consoles and more for decades then totally worth learning about.
You used to be able to sudo cat /proc/kcore > /dev/dsp and listen to your ram
Wouldn’t that just sound like gibberish? I feel like Mike Lindell would come out of the speakers.
That sounds really interesting! I couldn’t find anything else on this. Is this like pre-systemd?
The RAM whisperer.
Julia Evans has a bunch of these really handy cheatsheets. I have several saved that I reference semi-regularly.
Got to love UNIX’s everything is a file.
ProcFS is from Plan9. https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#/proc
Plan9 is worth a deep dive, but maybe not worth running. It is more UNIX than UNIX. (Also where UTF8 came from.)
I did not know that about plan9!
/procwas one of the things I missed most when I switched from daily driving linux to daily driving osx.Well that is retrograde of it.
Another cool thing from Plan9:
https://github.com/torvalds/linux/blob/master/Documentation/filesystems/9p.rst
/proc is quite useful when it comes to hiding root on Android.
I didn’t know any of this. Amazing. I usually just look at
/proc/net/for routes and bonding config etc.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 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.
I’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
Damn, I really could have made a lot of use of this over the last 20+ years… Thanks for sharing!
I am saving this, both for the post AND for the comments.
Did you know openBSD does not have this folder? I think the BSD’s do not use /proc. I do not know why though.
That raises the question of how their
ps,top,lsofand such work, since afaik in Linux they read from /proc.P.S. Looks like BSDs tug at the kernel via syscalls, namely
sysctland also the ‘kvm interface’ in the case of MacOS (not sure what ‘kvm’ thing is meant here). Seems vaguely reasonable, since procfs also queries the kernel for the info, so about the same resources would be used, perhaps even with the overhead of filesystem traversal and string-numbers conversion.I might be mistaken, but I think kvm stands for kernel virtual machine. Having no /proc, and interacting with sysctl instead sounds more secure, IMO.
