1. 33
  1.  

  2. 6

    the proc file system is great for all kinds of stuff: like determining where a process is in reading a file:

    https://gitlab.com/snippets/1757653

    Super useful when you have a process reading a massive file with no indication of progress.

    1. 3

      cp /proc/$pid/fd/$fd /tmp/important.conf is a classic sysadmin trick that I’ve actually used precisely one time to great applause (okay, extremely moderate appreciation).

      1. 1

        I recently found that one could actually see all the fd’s a process is using and now I am seeing this it’s so cool. I read a lot about “use strace, use ptrace” when do you actually use these? I work on small C projects and don’t really know when should I be using them.

        1. 2

          A few times recently I’ve wanted to know why a process wasn’t working properly. Looking at my bash history, I have run strace startx and strace openssl s_client -host rout.nz -port 443. If I remember correctly, I wanted to see the log output from startx which wasn’t being written to disk properly, and I wanted to see where openssl was looking for certificates.

          Both times I’m pretty sure I ran strace then grepped for things like open(, read(3 and write(3. There are probably better ways of doing this, but they worked for me both times.

      2. 2

        /proc is your worst enemy if race conditions are an issue.

        1. 1

          oh, interesting! Could you elaborate a bit more on that?

          1. 7

            top and ps are good examples, they need to open multiple files per process to gather all information. They iterate through /proc to collect all PIDs and then open each directory and then a few files in each directory. In some cases the process can be gone in between one of those steps, the PID could also be reused in this time frame. If you want to represent processes in a tree like structure it even more error prone.

            There is extrace a cool tool to trace system wide executions without attaching debuggers etc. it uses linuxs CONFIG_PROC_EVENTS to receive notifications about new processes and then reads some data from /proc to print some information about the process. In some cases really short lived processes are already gone when it receives the notification.

            Those are specific cases and procfs is nice in many other use cases, but sometimes I would like to have the kernel to provide me all of the information in a buffer in one go which represents the complete state when it was requested.

            tedu@ has a blog post about this in OpenBSD too, while its not procfs it still has some of the issues https://www.tedunangst.com/flak/post/process-listing-consistency

        2. 1

          This is a really fantastic, in-depth article. Thanks for writing it! I’m impressed you’ve gone even further and set yourself up for a month of these…

          1. 1

            bravo, this is exactly the kind of thing I want to read, substantive explorations of concepts I have only a superficial understanding of. looking forward to the rest!

            1. 1

              Great project to discover it is to re-implement vmstat or top reading from procfs. Many things to learn from that!

              Thanks for this challenge, I’m looking forward to the next entries! Good luck with it too!