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

91–100 of 111 posts

Re: Not knowing the /proc file system

#91

Post by a1369209993 »

Calzifer wrote: post #59

int s_isdigit(const char* s) { Name does not fit implementation. Should be "contains_digit". Also I would say almost any "issomething" method involving a loop has an opportunity for an early return.

As written, it should be `s_hasdigit`, but it's actually wrong - it should be:

  int s_isnum(const char* s) {
    int result = (*s != '\0');
    while (*s != '\0') {
        if ((*s
otherwise, it will choke on directories like `/proc/etc64/` or `/proc/net6/` if any such directory is added. (Plus other bits like early return, but that's not a correctness bug.)

Re: Not knowing the /proc file system

#92

Post by Animats »

fsckboy wrote: post #86
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].…

you're being too negative, it's as if you don't understand "worse is better". > If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. you make this sound like it's some arcane and tricky incantation; it's totally normal, like saying "to walk, put one foot in front of the other". It's unix file I/O 101, bufferless file operations are always atomic, it's a feature.…

See the example in the original article. The article author does not know they have to do that, and wrote code which uses "fread".

Re: Not knowing the /proc file system

#93

Post by TristanBall »

mzs wrote: post #84
williamcotton wrote: post #32

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.…

I like your style, but it's not quite right: $ echo /proc/[0-9]/status | wc 1 7 105 $ echo /proc/[1-9]*/status | wc 1 483 8778 It also will sporadically print error messages due to all the race conditions. Here's my stab at it: $ cat dumbps #!/bin/sh case $# in 1) ;; *) echo "Usage: dumbps user" >&2 exit 2 ;; esac 2>&- find /proc -mindepth 2 -maxdepth 2 -type f -name status -user "$1" | awk '{ while ((getline li 0) {…

You seem to have very similar races here though?

Perfectly possible, even likely, for a process to end between "find" finding it and awk opening it... especially given the pipe buffer between the two.

Personly I'd rather an "expect errors" approach.. break it out so that you can easily treat a failed open as a "continue next" scenario and hide just those errors

Re: Not knowing the /proc file system

#94

Post by mzs »

TristanBall wrote: post #93
mzs wrote: post #84

Earlier quoted context omitted.

I like your style, but it's not quite right: $ echo /proc/[0-9]/status | wc 1 7 105 $ echo /proc/[1-9]*/status | wc 1 483 8778 It also will sporadically print error messages due to all the race conditions. Here's my stab at it: $ cat dumbps #!/bin/sh case $# in 1) ;; *) echo "Usage: dumbps user" >&2 exit 2 ;; esac 2>&- find /proc -mindepth 2 -maxdepth 2 -type f -name status -user "$1" | awk '{ while ((getline li 0) {…

You seem to have very similar races here though? Perfectly possible, even likely, for a process to end between "find" finding it and awk opening it... especially given the pipe buffer between the two. Personly I'd rather an "expect errors" approach.. break it out so that you can easily treat a failed open as a "continue next" scenario and hide just those errors

2>&- hides races in find itself

while ((getline li 0) hides races in awk

in practice Name: is the first line so cmd is not truncated

Of course I got my test wrong though :D

  $ time ./dumbps 0 >/dev/null
  
  real 0m0.030s
  user 0m0.012s
  sys 0m0.022s

Re: Not knowing the /proc file system

#95

Post by dilyevsky »

lathiat wrote: post #34
themulticaster wrote: post #21

Earlier quoted context omitted.

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.

Solaris descendants like SmartOS were also heavy on xml configs as I recall

Re: Not knowing the /proc file system

#96

Post by IggleSniggle »

MayeulC wrote: post #42
IggleSniggle wrote: post #22

Earlier quoted context omitted.

8-wide tab is still just 1 char of your 80 allotted. Just sayin'.

Nah, kernel coding style counts tabs as 8 characters for indentation purposes. It is also discouraged to nest conditional structures too deeply. Here's the very opinionated documentation: https://www.kernel.org/doc/html/v6.5/process/coding-style.ht... I also want to note that the 80 columns limit was bumped to 100, and is no longer strictly enforced: https://www.phoronix.com/news/Linux-Kernel-Deprecates-80-Col

I wasn't entirely convinced by the opinionated style doc that 80 meant columns and not characters (of COURSE it means columns, the opposite would be nonsense, but sometimes I get stubborn), so I looked up the kernel repo and indeed, my comment didn't pass the sniff test OR the scripts/checkpatch.pl test, where the max_line_length is enforced using calls to expand_tab, which converts tabs into 8 spaces before checking the length of the line.

Re: Not knowing the /proc file system

#97

Post by yakubin »

JdeBP wrote: post #53
chasil wrote: post #50

Earlier quoted context omitted.

I believe that the /proc filesystem first appeared commercially in Solaris, and was then adopted and expanded in Linux. I got an SDF account recently, and was surprised to find it in NetBSD. OpenBSD has great resistance to it. ...looking at the wiki, many more kernels implement /proc: "Many Unix-like operating systems support the proc filesystem, including Solaris, IRIX, Tru64 UNIX, BSD, Linux, IBM AIX, QNX, and Plan…

The problem is Wikipedia being misleading again. They each support a proc filesystem. There is no single the proc filesystem that they support. A case in point: FreeBSD's /proc is very different to Linux's /proc, and most of what one would go to /proc on Linux for is obtained via sysctl() on FreeBSD, with a lot less in the way of machine readable → human readable → machine readable busywork formatting and re-parsing…

By default, FreeBSD, just like OpenBSD, doesn’t have a /proc. I’m actually running a server without it.

Re: Not knowing the /proc file system

#98

Post by yakubin »

chasil wrote: post #50
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].…

I believe that the /proc filesystem first appeared commercially in Solaris, and was then adopted and expanded in Linux. I got an SDF account recently, and was surprised to find it in NetBSD. OpenBSD has great resistance to it. ...looking at the wiki, many more kernels implement /proc: "Many Unix-like operating systems support the proc filesystem, including Solaris, IRIX, Tru64 UNIX, BSD, Linux, IBM AIX, QNX, and Plan…

/proc appeared in late versions of original Unix. That’s where BSDs inherited it from before ripping it out.

Re: Not knowing the /proc file system

#99

Post by pjmlp »

dilyevsky wrote: post #95
lathiat wrote: post #34

Earlier quoted context omitted.

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.

Solaris descendants like SmartOS were also heavy on xml configs as I recall

Like all NeXTSTEP ones.

Re: Not knowing the /proc file system

#100

Post by yakubin »

Terr_ wrote: post #71
enriquto wrote: post #64

Earlier quoted context omitted.

> Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. I definitely make a point of using only single-letter variables in most of my C and python programs. It is a very common usage in scientific computing. In math, all variables are single letters. Always. If a variable has more than one letter, you rea…

That one lands near the margin-of-error for my sarcasmometer, but either way I'd like to emphasize (non-ironically) that the terse form is indeed very efficient... for someone repeatedly writing/copying it down by hand using a quill and ink. However that particular use-case has become dramatically less significant.

The terseness is useful not just for writing, but also for reading. In maths, the shape of a formula is often more important than what each symbol in a formula “means”. The terse notation allows you to quickly grasp the shape and draw parallels between seemingly distinct areas of mathematics, as well as transform the shapes in your head without being bogged down by whether A is a matrix, a real number, a function or whatever.

When I code, I prefer comments explaining the general idea of what’s happening and why in a given folder/file/section (not explaining each line) combined with terse code.

Post reply on HN