Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not knowing the /proc file system

admccartney.mur.at

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Not knowing the /proc file system

#31

Post by lifthrasiir »

rascul wrote: post #24
lifthrasiir wrote: post #7

Earlier quoted context omitted.

Maybe your tangent is pointing at a wrong direction, because I think there are also a sizable portion of such programmers in many other languages. It seems that anOverlyLongAndInformationFreeIdentifier is widely despised, but once names do have enough information contents, an exactly preferred name wildly varies even in a single code base. For example induction variables in Python generators tended to be shorter than…

> anOverlyLongAndInformationFreeIdentifier Apple has one 82 characters. https://developer.apple.com/documentation/contacts/cnlabelco...

It is not information-free though. It describes what it actually is, and no one could agree on a shorter and unambiguous term. I personally prefer `CNLabelContactRelationBiaoMei` just in case [1].

[1] https://news.ycombinator.com/item?id=37607801

Re: Not knowing the /proc file system

#32

Post by williamcotton »

This is running in a barebones Ubuntu container on my MacBook as BSDs don't use /proc:

  root@74c03a282fbe:/# ed
  a
  ls /proc/[0-9]/status | xargs -n 1 cat | awk '/^Name:/ { name = $2 } /^Pid:/ { pid = $2 } END { print "cmd: " name ", pid: " pid }'
  .
  w prc.sh
  132
  q
  root@74c03a282fbe:/# chmod +x ./prc.sh
  root@74c03a282fbe:/# hyperfine --warmup=100 "./prc.sh"
  Benchmark 1: ./prc.sh
    Time (mean ± σ):       2.2 ms ±   0.3 ms    [User: 1.3 ms, System: 2.7 ms]
    Range (min … max):     1.8 ms …   5.0 ms    880 runs
   
    Warning: Command took less than 5 ms to complete. Results might be inaccurate.
    Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet PC without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Re: Not knowing the /proc file system

#33

Post by iforgotpassword »

knome wrote: post #16
dale_glass wrote: post #9

Earlier quoted context omitted.

Yup. Some parts of the API are a huge annoyance like that. Also there's no guarantee whatsoever that /proc/123 is going to refer to a specific process, or to remain existing while you get all the data you need. The whole API is full of race conditions.

>Also there's no guarantee whatsoever that /proc/123 is going to refer to a specific process does using openat solve that or is there some kind of directory inode reuse occurring?

No, that's usually the way to go, although I couldn't guarantee you that inodes could theoretically get reused; I never checked. I would assume you don't reuse an inode that's still in use...

Re: Not knowing the /proc file system

#34

Post by lathiat »

themulticaster wrote: post #21
ahoka wrote: post #17

Earlier quoted context omitted.

“The Linux kernel has no standard mechanism for delivering a variable-sized result from a system call.” In NetBSD you can create XML serialized system calls for this. :-)

Of all the BSDs, I'm only a little familiar with OpenBSD through its OpenSSH fame, so I'm a little surprised to hear that a (probably) somewhat related project would use XML in a system call. In other words, if an OpenSSH release introduced XML as a wire format I'd assume it to be an April fools's joke. [1] But I guess OpenBSD and NetBSD are less related than I thought.

Before JSON and YAML, XML was all the rage in the sort of 2000-2005 era. Plenty of config files etc using it in the Linux desktop space.

Not sure if it’s related to this case or not but it was once much more popular even for sometimes human written files.

Re: Not knowing the /proc file system

#35

Post by lathiat »

knome wrote: post #16
dale_glass wrote: post #9

Earlier quoted context omitted.

Yup. Some parts of the API are a huge annoyance like that. Also there's no guarantee whatsoever that /proc/123 is going to refer to a specific process, or to remain existing while you get all the data you need. The whole API is full of race conditions.

>Also there's no guarantee whatsoever that /proc/123 is going to refer to a specific process does using openat solve that or is there some kind of directory inode reuse occurring?

See also, pidfd, for similar reasons: https://lwn.net/Articles/794707/

Re: Not knowing the /proc file system

#36

Post by sneed_chucker »

themulticaster wrote: post #21
ahoka wrote: post #17

Earlier quoted context omitted.

“The Linux kernel has no standard mechanism for delivering a variable-sized result from a system call.” In NetBSD you can create XML serialized system calls for this. :-)

Of all the BSDs, I'm only a little familiar with OpenBSD through its OpenSSH fame, so I'm a little surprised to hear that a (probably) somewhat related project would use XML in a system call. In other words, if an OpenSSH release introduced XML as a wire format I'd assume it to be an April fools's joke. [1] But I guess OpenBSD and NetBSD are less related than I thought.

Free, Net, and Open BSD are all relatively early forks of the same 386BSD project from the early 90s. Each project has different goals and code has diverged between them, though they frequently pull in changes from on another's codebases.

FreeBSD is the most general purpose of the 3 and the most popular. It is also the only BSD out of the big 3 that doesn't utilize a global kernel lock, allowing for modern symmetric multiprocessing similar to Linux.

NetBSD is aimed at being extremely portable. It's sort of like the "Can it run doom" of the OS world. Just take a look at their list of ports: https://wiki.netbsd.org/ports/

OpenBSD is aimed at being secure. Exactly how realized this goal is is somewhat controversial. But regardless of that, security is the stated highest priority of the development team.

There's also DragonflyBSD, which was forked by Matt Dillon from FreeBSD following some personal and technical disagreements. It's since diverged pretty heavily from the rest of the BSD family. Given its very low market share in this category of already niche operating systems, it seems more like a pet project of Matt Dillon's, though I'm sure it has serious users.

Re: Not knowing the /proc file system

#37

Post by dezgeg »

Someone wrote: post #23
Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

> If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions AFAIK, as that StackOverflow page also says, that’s not guaranteed to be possible. https://man7.org/linux/man-pages/man2/read.2.html : “RETURN VALUE On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number…

In practice signals don't seem to be a problem for (most?) proc files as the seq_file infrastructure doesn't bother to check for pending signals and terminate the read if so.

Naturally, only source reading will answer whether the proc file you're interested in is vulnerable to this or not.

Re: Not knowing the /proc file system

#38

Post by touisteur »

Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

Some of the /proc APIs have been plugged into netlink and can be used from there. Nicer interface if you can embed libnl or libmnl.

Re: Not knowing the /proc file system

#39

Post by tanelpoder »

linuxftw wrote: post #25

I use the /proc file system all the time. Often containers don't have ps or several other tools installed, so you can use /proc to find out how a process started, open file descriptors, open sockets, and a bunch of other information. In fact, many user-space tools like netstat are just purpose-built readers of things in /proc.

Same here, you can get pretty far with just catting, grepping, awk/sed/sort/uniq'ing all the various /proc entries. And not only /proc/PID/stuff, but also each individual thread (task) state from /proc/PID/task/TID/* too.

Initially I wrote a python program for flexible querying & summarizing of what the threads of interest are doing (psn) and then wrote a C version to capture & save a sampled history of thread activity (xcapture) [1]. I ended up spending too much time optimizing the C code - as just formatting strings taken from /proc pseudofiles and printing them out took very little time compared to the kernel-dives when extracting things like WCHAN and kernel stack via the proc intereface.

That's why I've since built an eBPF prototype for sampling the OS thread activity. The old approach still works even on RHEL5 machines with 2.6.x kernels without root access too :-)

[1] https://0x.tools/#usage--example-output

Post reply on HN