Check out my first novel, midnight's simulacra!
Procfs: Difference between revisions
(Created page with "procfs began life (on Solaris?) as a virtual filesystem dedicated to exporting process information. Over time, it has grown substantially on any number of operating systems. I...") |
No edit summary |
||
| Line 1: | Line 1: | ||
procfs began life (on Solaris?) as a virtual filesystem dedicated to exporting process information. Over time, it has grown substantially on any number of operating systems. It is pretty much a required interface on [[Linux APIs|Linux]], and strongly recommended on Solaris and [[FreeBSD]]. | procfs began life (on Solaris?) as a virtual filesystem dedicated to exporting process information. Over time, it has grown substantially on any number of operating systems. It is pretty much a required interface on [[Linux APIs|Linux]], and strongly recommended on Solaris and [[FreeBSD]]. | ||
==proc/PID== | |||
Each entity associated with a non-zero PID (this includes most kernel threads) has a corresponding toplevel procfs directory named by its PID (e.g. when using [[systemd]] as init and mounting procfs at `/proc`, systemd's primary process is described by `/proc/1` (the process only appears in procfs mounts within the same PID namespace). One of the entries is `proc/PID/task`, a directory which contains the threads making up the process, using the TID as name: | |||
<pre> | |||
[schwarzgerat](1) $ grep ^Threads: /proc/`pidof rtorrent`/status | |||
Threads: 3 | |||
[schwarzgerat](0) $ ls /proc/`pidof rtorrent`/task | |||
4282 4283 4309 | |||
[schwarzgerat](0) $ | |||
</pre> | |||
procfs since Linux 3.3 accepts a mount option `hidepid`, taking one of three values: | |||
* 0: everyone may access all `proc/PID` directories | |||
* 1: users can only access their own `proc/PID` directories | |||
* 2: users can only *see* their own `proc/PID` directories | |||
Linux 3.3 also introduced the `gid` parameter, which specifies a group ID. Members of this group are exempted from `hidepid` restrictions. | |||
===proc/PID/stat sucks=== | |||
`/proc/PID/stat` | |||
==See Also== | ==See Also== | ||
* The [[sysfs]] page | * The [[sysfs]] page | ||
Revision as of 13:38, 11 October 2019
procfs began life (on Solaris?) as a virtual filesystem dedicated to exporting process information. Over time, it has grown substantially on any number of operating systems. It is pretty much a required interface on Linux, and strongly recommended on Solaris and FreeBSD.
proc/PID
Each entity associated with a non-zero PID (this includes most kernel threads) has a corresponding toplevel procfs directory named by its PID (e.g. when using systemd as init and mounting procfs at `/proc`, systemd's primary process is described by `/proc/1` (the process only appears in procfs mounts within the same PID namespace). One of the entries is `proc/PID/task`, a directory which contains the threads making up the process, using the TID as name:
[schwarzgerat](1) $ grep ^Threads: /proc/`pidof rtorrent`/status Threads: 3 [schwarzgerat](0) $ ls /proc/`pidof rtorrent`/task 4282 4283 4309 [schwarzgerat](0) $
procfs since Linux 3.3 accepts a mount option `hidepid`, taking one of three values:
- 0: everyone may access all `proc/PID` directories
- 1: users can only access their own `proc/PID` directories
- 2: users can only *see* their own `proc/PID` directories
Linux 3.3 also introduced the `gid` parameter, which specifies a group ID. Members of this group are exempted from `hidepid` restrictions.
proc/PID/stat sucks
`/proc/PID/stat`
See Also
- The sysfs page
