/proc and /sys filesystems ... Some bits from yesterday's BALUG meeting.

There was some response and more information that also came up on the SF-LUG list: http://linuxmafia.com/pipermail/sf-lug/2018q3/013428.html http://linuxmafia.com/pipermail/sf-lug/2018q3/013430.html

And (mostly) from the BALUG meeting ... mostly lots of folks various favorite bits and other things /proc and /sys discussed:

Is it virtual? Don't have dmidecode(8) or similar? $ cat /sys/devices/virtual/dmi/id/product_name Can even work that into use in a script, e.g. #!/bin/sh #... case ... 'Bochs'|'HVM domU'|'VMware'*|'VirtualBox') The above would respectively match virtual machines of (at least some of) the varieties: QEMU/KVM Xen VMware VirtualBox

I have /dev/sda and /dev/sdb as internal drives, I insert two USB flash drives at about the same time, giving me now also /dev/sdc and /dev/sdd. One's about 2 GB in size, and the other about 32 GB. Which is which? $ grep . /sys/block/sd[cd]/size /sys/block/sdc/size:4089856 /sys/block/sdd/size:62530624 $ What are their exact sizes? ... Oh, we also have that above - in the number of 512 byte blocks I'm done with /dev/sdc, I pull it out. $ ls -d /dev/sd[c-z] /dev/sdd $ At present I'm not using /dev/sdd (nothing having it open or mounted from it, etc.), I'd really like it as /dev/sdc rather than sdb, but I don't feel like taking my fingers away from the keyboard or adding the wear and tear to the USB connectors. This removes it: # echo 1 > /sys/block/sdd/device/delete # $ ls -d /dev/sd[c-z] 2>>/dev/null $ This scans for drives: # (>>/dev/null 2>&1 ls -d /sys/class/scsi_host/host*/scan && for tmp in /sys/class/scsi_host/host*/scan; do echo '- - -' > "$tmp"; done) # $ ls -d /dev/sd[c-z] && grep . /sys/block/sd[c-z]/size /dev/sdc 62530624 $ I plug in an additional USB flash device: $ ls -d /dev/sd[c-z] /dev/sdc /dev/sdd $ What if their sizes weren't all that different, but I wanted to know which was which? ls -d /sys/block/sd[cd]/device/* $ (cd /sys/block && grep . sd[c-z]/device/vendor sd[c-z]/device/model) | sort sdc/device/model:Cruzer Blade sdc/device/vendor:SanDisk sdd/device/model:USB 2.0 sdd/device/vendor: $

/proc/[0-9]* - PIDs (and that much will match not only Linux, but also as far as I'm aware, any other *nix flavor (notably Unix) that also has a mounted /proc filesystem) /proc/[!0-9]* - lots of other interesting/useful non-PID stuff /proc/PID/fd/* - open file descriptors for the PID - these are represented as symbolic links to the physical pathname of the file (at least for filesystem files), if the file is unlinked, it will have " (deleted)" on the end; 0 is stdin, 1 stdout, 2 stderr. I have some PID of some something I'm unfamiliar with - maybe it's undocumented ... maybe I want to know if it's writing some log information ... may be quite useful to look at /proc/PID/fd/[12] - it may possibly be there, ... or possibly some other file(s) it has open (especially if it's not using syslog). File unlinked, but need to save/retrieve the data (it's still open by the PID)?: $ cat /proc/PID/fd/file_descriptor_number > file_to_save_data_in /proc/PID/environ - what's in the environment (each ASCII null terminated) /proc/PID/exe - the binary executable /proc/PID/cwd - Current Working Directory When exactly did that process start? $ stat -c '%z' /proc/PID Grew (or shrunk) the size of a device (e.g. LUN), want the kernel to know about it? E.g.: # echo 1 > /sys/block/sdb/device/rescan /proc/cpuinfo - lots of useful information about the CPU(s), flags may be of particular note (e.g. is your CPU 64 or 32 bit - how old of which kernel/distribution can it still run ... or run without additional kernel parameters to enable use of some CPU feature present on the CPU but which the CPU doesn't "advertise"). What CPU hardware bugs are worked around (or partially so) via kernel software? How many cores? ... /proc/cmdline - what arguments were given to the kernel at boot? /proc/version - kernel version /proc/sys - a precursor to the /sys filesystem, also much kernel information and tunable parameters there - see also sysctl(8) /proc/mounts - kernel's idea of what's mounted and how - this is especially useful when /etc/mtab doesn't fully or well provide that information. Note that for many distributions, /etc/mtab may be a symbolic link to /proc/mounts.

Especially the /proc filesystem, and also /sys filesystem are relatively essential in Linux. E.g. without /proc filesystem mounted, many common utilities, e.g. ps(1), won't work.

Backup /proc and /sys filesystems? You generally would *not* want to do that. They're pseudo (/"virtual") filesystems, most notably reflecting lots of state information of the current running system. But they're ephemeral/volatile - prior contents don't really matter at all after a reboot.