[BALUG-Talk] /proc and /sys filessytems

[Michael Paoli]

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