Check out my first novel, midnight's simulacra!
Procfs: Difference between revisions
No edit summary |
No edit summary |
||
Line 2: | Line 2: | ||
==proc/PID== | ==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 | 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 <tt>/proc</tt>, systemd's primary process is described by <tt>/proc/1</tt> (the process only appears in procfs mounts within the same PID namespace). One of the entries is <tt>proc/PID/task</tt>, a directory which contains the threads making up the process, using the TID as name: | ||
<pre> | <pre> | ||
Line 12: | Line 12: | ||
</pre> | </pre> | ||
procfs since Linux 3.3 accepts a mount option | procfs since Linux 3.3 accepts a mount option <tt>hidepid</tt>, taking one of three values: | ||
* 0: everyone may access all | * 0: everyone may access all <tt>proc/PID` directories | ||
* 1: users can only access their own | * 1: users can only access their own <tt>proc/PID</tt> directories | ||
* 2: users can only *see* their own | * 2: users can only *see* their own <tt>proc/PID</tt> directories | ||
Linux 3.3 also introduced the | Linux 3.3 also introduced the <tt>gid</tt> parameter, which specifies a group ID. Members of this group are exempted from <tt>hidepid</tt> restrictions. | ||
===proc/PID/stat sucks=== | ===proc/PID/stat sucks=== | ||
<tt>/proc/PID/stat</tt> | |||
==See Also== | ==See Also== | ||
* The [[sysfs]] page | * The [[sysfs]] page |
Revision as of 13:40, 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