stuff in /proc/PID/
Table of Contents
- 1. /proc/PID/cwd
- 2. /proc/PID/clear_refs
- 3. /proc/PID/coredump_filter
- 4. /proc/PID/environ
- 5. /proc/PID/exe
- 6. /proc/PID/fd
- 7. /proc/PID/io8. /proc/PID/limits
- 7.1. rchar. I/O counter: chars read
- 7.2. wchar. I/O counter: chars written
- 7.3. syscr. I/O counter: read syscalls
- 7.4. syscw. I/O counter: write syscalls
- 7.5. read_bytes. I/O counter: bytes read
- 7.6. write_bytes. I/O counter: bytes written
- 7.7. cancelled_write_bytes. The big inaccuracy here is truncate.
- 9. /proc/PID/maps
- 10. /proc/PID/mem
- 11. /proc/PID/mountinfo
- 12. /proc/PID/mounts
- 13. /proc/PID/mountstats
- 14. /proc/PID/oom_adj
- 15. /proc/PID/oom_score
- 16. /proc/PID/oom_score_adj
- 17. /proc/PID/pagemap
- 18. /proc/PID/nuwa_maps
- 19. /proc/PID/root
- 20. /proc/PID/sched
- 21. /proc/PID/smaps
- 22. /proc/PID/stack
- 23. /proc/PID/stat
- 24. /proc/PID/statm
- 25. /proc/PID/status
- 26. /proc/PID/syscall
- 27. /proc/PID/wchan
- 28. /proc/PID/task
- 29. /proc/PID/fdinfo
- 30. References:
1 /proc/PID/cwd
A symlink to the current working directory of the process.
2 /proc/PID/clear_refs
Used to reset the PG_Referenced and ACCESSED/YOUNG bits on both physical and virtual pages associated with a process, and the soft-dirty bit on pte (see Documentation/vm/soft-dirty.txt for details).
To clear the bits for all the pages associated with the process
> echo 1 > /proc/PID/clear_refs
To clear the bits for the anonymous pages associated with the process
> echo 2 > /proc/PID/clear_refs
To clear the bits for the file mapped pages associated with the process
> echo 3 > /proc/PID/clear_refs
To clear the soft-dirty bit
> echo 4 > /proc/PID/clear_refs
To reset the peak resident set size ("high water mark") to the process's current value:
> echo 5 > /proc/PID/clear_refs
Any other value written to /proc/PID/clear\_refs will have no effect.
3 /proc/PID/coredump_filter
When a process is dumped, all anonymous memory is written to a core file as long as the size of the core file isn't limited. But sometimes we don't want to dump some memory segments, for example, huge shared memory or DAX.
Conversely, sometimes we want to save file-backed memory segments into a core file, not only the individual files.
/proc/<pid>/coredump_filter allows you to customize which memory segments will be dumped when the <pid> process is dumped. coredump_filter is a bitmask of memory types. If a bit of the bitmask is set, memory segments of the corresponding memory type are dumped, otherwise they are not dumped.
The following 9 memory types are supported:
- (bit 0) anonymous private memory
- (bit 1) anonymous shared memory
- (bit 2) file-backed private memory
- (bit 3) file-backed shared memory
- (bit 4) ELF header pages in file-backed private memory areas (it is effective only if the bit 2 is cleared)
- (bit 5) hugetlb private memory
- (bit 6) hugetlb shared memory
- (bit 7) DAX private memory
- (bit 8) DAX shared memory
Note that MMIO pages such as frame buffer are never dumped and vDSO pages are always dumped regardless of the bitmask status.
Note that bits 0-4 don't affect hugetlb or DAX memory. hugetlb memory is only affected by bit 5-6, and DAX is only affected by bits 7-8.
The default value of coredump_filter is 0x33; this means all anonymous memory segments, ELF header pages and hugetlb private memory are dumped.
If you don't want to dump all shared memory segments attached to pid 1234, write 0x31 to the process's proc file.
$ echo 0x31 > /proc/1234/coredump_filter
When a new process is created, the process inherits the bitmask status from its parent. It is useful to set up coredump_filter before the program runs.
For example:
$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program
4 /proc/PID/environ
Contains the names and values of the environment variables that affect the process.
5 /proc/PID/exe
A symlink to the original executable file, if it still exists (a process may continue running after its original executable has been deleted or replaced).
6 /proc/PID/fd
A directory containing a symbolic link for each open file descriptor.
7 /proc/PID/io
This file contains IO statistics for each running process
7.1 rchar. I/O counter: chars read
The number of bytes which this task has caused to be read from storage. This is simply the sum of bytes which this process passed to read() and pread(). It includes things like tty IO and it is unaffected by whether or not actual physical disk IO was required (the read might have been satisfied from pagecache)
7.2 wchar. I/O counter: chars written
The number of bytes which this task has caused, or shall cause to be written to disk. Similar caveats apply here as with rchar.
7.3 syscr. I/O counter: read syscalls
Attempt to count the number of read I/O operations, i.e. syscalls like read() and pread().
7.4 syscw. I/O counter: write syscalls
Attempt to count the number of write I/O operations, i.e. syscalls like write() and pwrite().
7.5 read_bytes. I/O counter: bytes read
Attempt to count the number of bytes which this process really did cause to be fetched from the storage layer. Done at the submit_bio() level, so it is accurate for block-backed filesystems. <please add status regarding NFS and CIFS at a later time>
7.6 write_bytes. I/O counter: bytes written
Attempt to count the number of bytes which this process caused to be sent to the storage layer. This is done at page-dirtying time.
7.7 cancelled_write_bytes. The big inaccuracy here is truncate.
If a process writes 1MB to a file and then deletes the file, it will in fact perform no writeout. But it will have been accounted as having caused 1MB of write. In other words: The number of bytes which this process caused to not happen, by truncating pagecache. A task can cause "negative" IO too. If this task truncates some dirty pagecache, some IO which another task has been accounted for (in its write_bytes) will not be happening. We could just subtract that from the truncating task's write_bytes, but there is information loss in doing that.
8 /proc/PID/limits
This file displays the soft limit, hard limit, and units of measurement for each of the process's resource limits (seegetrlimit(2)). Up to and including Linux 2.6.35, this file is protected to only allow reading by the real UID of the process. Since Linux 2.6.36, this file is readable by all users on the system.
9 /proc/PID/maps
containing the currently mapped memory regions and their access permissions. The format is:
address perms offset dev inode pathname
08048000-08049000 r-xp 00000000 03:00 8312 /opt/test
08049000-0804a000 rw-p 00001000 03:00 8312 /opt/test
0804a000-0806b000 rw-p 00000000 00:00 0 [heap]
a7cb1000-a7cb2000 ---p 00000000 00:00 0
a7cb2000-a7eb2000 rw-p 00000000 00:00 0
a7eb2000-a7eb3000 ---p 00000000 00:00 0
a7eb3000-a7ed5000 rw-p 00000000 00:00 0
a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6
a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6
a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6
a800b000-a800e000 rw-p 00000000 00:00 0
a800e000-a8022000 r-xp 00000000 03:00 14462 /lib/libpthread.so.0
a8022000-a8023000 r--p 00013000 03:00 14462 /lib/libpthread.so.0
a8023000-a8024000 rw-p 00014000 03:00 14462 /lib/libpthread.so.0
a8024000-a8027000 rw-p 00000000 00:00 0
a8027000-a8043000 r-xp 00000000 03:00 8317 /lib/ld-linux.so.2
a8043000-a8044000 r--p 0001b000 03:00 8317 /lib/ld-linux.so.2
a8044000-a8045000 rw-p 0001c000 03:00 8317 /lib/ld-linux.so.2
aff35000-aff4a000 rw-p 00000000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
where "address" is the address space in the process that it occupies
"perms" is a set of permissions:
r = read
w = write
x = execute
s = shared
p = private (copy on write)
"offset" is the offset into the mapping
"dev" is the device (major:minor)
"inode" is the inode on that device. 0 indicates that no inode is associated with the memory region, as the case would be with BSS (uninitialized data).
"pathname" shows the name associated file for this mapping. If the mapping is not associated with a file:
[heap] = the heap of the program
[stack] = the stack of the main process
[vdso] = the "virtual dynamic shared object",
the kernel system call handler
or if empty, the mapping is anonymous.
The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint of the individual tasks of a process. In this file you will see a mapping marked as [stack] if that task sees it as a stack. Hence, for the example above, the task-level map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like this:
08048000-08049000 r-xp 00000000 03:00 8312 /opt/test
08049000-0804a000 rw-p 00001000 03:00 8312 /opt/test
0804a000-0806b000 rw-p 00000000 00:00 0 [heap]
a7cb1000-a7cb2000 ---p 00000000 00:00 0
a7cb2000-a7eb2000 rw-p 00000000 00:00 0
a7eb2000-a7eb3000 ---p 00000000 00:00 0
a7eb3000-a7ed5000 rw-p 00000000 00:00 0 [stack]
a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6
a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6
a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6
a800b000-a800e000 rw-p 00000000 00:00 0
a800e000-a8022000 r-xp 00000000 03:00 14462 /lib/libpthread.so.0
a8022000-a8023000 r--p 00013000 03:00 14462 /lib/libpthread.so.0
a8023000-a8024000 rw-p 00014000 03:00 14462 /lib/libpthread.so.0
a8024000-a8027000 rw-p 00000000 00:00 0
a8027000-a8043000 r-xp 00000000 03:00 8317 /lib/ld-linux.so.2
a8043000-a8044000 r--p 0001b000 03:00 8317 /lib/ld-linux.so.2
a8044000-a8045000 rw-p 0001c000 03:00 8317 /lib/ld-linux.so.2
aff35000-aff4a000 rw-p 00000000 00:00 0
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
10 /proc/PID/mem
A binary image representing the process's virtual memory, can only be accessed by a ptrace'ing process.
11 /proc/PID/mountinfo
This file contains information about mount points. It contains lines of the form:
This file contains lines of the form:
36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
(1) mount ID: unique identifier of the mount (may be reused after umount)
(2) parent ID: ID of parent (or of self for the top of the mount tree)
(3) major:minor: value of st_dev for files on filesystem
(4) root: root of the mount within the filesystem
(5) mount point: mount point relative to the process's root
(6) mount options: per mount options
(7) optional fields: zero or more fields of the form "tag[:value]"
(8) separator: marks the end of the optional fields
(9) filesystem type: name of filesystem of the form "type[.subtype]"
(10) mount source: filesystem specific information or "none"
(11) super options: per super block options
12 /proc/PID/mounts
This is a list of all the file systems currently mounted in the process's mount namespace. The format of this file is documented in fstab(5). Since kernel version 2.6.15, this file is pollable: after opening the file for reading, a change in this file (i.e., a file system mount or unmount) causes select(2) to mark the file descriptor as readable, and poll(2) and epoll_wait(2) mark the file as having an error condition.
13 /proc/PID/mountstats
This file exports information (statistics, configuration information) about the mount points in the process's name space. Lines in this file have the form:
device /dev/sda7 mounted on /home with fstype ext3 [statistics]
( 1 ) ( 2 ) (3 ) (4)
The fields in each line are:
(1) The name of the mounted device (or "nodevice" if there is no corresponding device).
(2) The mount point within the file system tree.
(3) The file system type.
(4) Optional statistics and configuration information. Currently (as at Linux 2.6.26), only NFS file systems export information via this field.
This file is only readable by the owner of the process.
14 /proc/PID/oom_adj
This file can be used to adjust the score used to select which process should be killed in an out-of-memory (OOM) situation. The kernel uses this value for a bit-shift operation of the process's oom_score value: valid values are in the range -16 to +15, plus the special value -17, which disables OOM-killing altogether for this process. A positive score increases the likelihood of this process being killed by the OOM-killer; a negative score decreases the likelihood.
The default value for this file is 0; a new process inherits its parent's oom_adj setting. A process must be privileged (CAP_SYS_RESOURCE) to update this file.
Since Linux 2.6.36, use of this file is deprecated in favor of /proc/[pid]/oom_score_adj.
15 /proc/PID/oom_score
This file can be used to check the current score used by the oom-killer is for any given <pid>. Use it together with /proc/<pid>/oom_score_adj to tune which process should be killed in an out-of-memory situation.
The basis for this score is the amount of memory used by the process, with increases (+) or decreases (-) for factors including:
- whether the process creates a lot of children using fork(2) (+);
- whether the process has been running a long time, or has used a lot of CPU time (-);
- whether the process has a low nice value (i.e., > 0) (+);
- whether the process is privileged (-); and
- whether the process is making direct hardware access (-).
The oom_score also reflects the adjustment specified by the oom_score_adj or oom_adj setting for the process.
16 /proc/PID/oom_score_adj
These file can be used to adjust the badness heuristic used to select which process gets killed in out of memory conditions.
The badness heuristic assigns a value to each candidate task ranging from 0 (never kill) to 1000 (always kill) to determine which process is targeted. The units are roughly a proportion along that range of allowed memory the process may allocate from based on an estimation of its current memory and swap use. For example, if a task is using all allowed memory, its badness score will be 1000. If it is using half of its allowed memory, its score will be 500.
There is an additional factor included in the badness score: the current memory and swap usage is discounted by 3% for root processes.
The amount of "allowed" memory depends on the context in which the oom killer was called. If it is due to the memory assigned to the allocating task's cpuset being exhausted, the allowed memory represents the set of mems assigned to that cpuset. If it is due to a mempolicy's node(s) being exhausted, the allowed memory represents the set of mempolicy nodes. If it is due to a memory limit (or swap limit) being reached, the allowed memory is that configured limit. Finally, if it is due to the entire system being out of memory, the allowed memory represents all allocatable resources.
The value of /proc/<pid>/oom_score_adj is added to the badness score before it is used to determine which task to kill. Acceptable values range from -1000 (OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). This allows userspace to polarize the preference for oom killing either by always preferring a certain task or completely disabling it. The lowest possible value, -1000, is equivalent to disabling oom killing entirely for that task since it will always report a badness score of 0.
Consequently, it is very simple for userspace to define the amount of memory to consider for each task. Setting a /proc/<pid>/oom_score_adj value of +500, for example, is roughly equivalent to allowing the remainder of tasks sharing the same system, cpuset, mempolicy, or memory controller resources to use at least 50% more memory. A value of -500, on the other hand, would be roughly equivalent to discounting 50% of the task's allowed memory from being considered as scoring against the task.
For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also be used to tune the badness score. Its acceptable values range from -16 (OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17 (OOM_DISABLE) to disable oom killing entirely for that task. Its value is scaled linearly with /proc/<pid>/oom_score_adj.
The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last value set by a CAP_SYS_RESOURCE process. To reduce the value any lower requires CAP_SYS_RESOURCE.
17 /proc/PID/pagemap
The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags using /proc/kpageflags and number of times a page is mapped using /proc/kpagecount. For detailed explanation, see Documentation/vm/pagemap.txt.
18 /proc/PID/nuwa_maps
An extension based on maps, showing the memory locality and binding policy, as well as the memory usage (in pages) of each mapping. The output follows a general format where mapping details get summarized separated by blank spaces, one mapping per each file line:
address policy mapping details
00400000 default file=/usr/local/bin/app mapped=1 active=0 N3=1 kernelpagesize_kB=4
00600000 default file=/usr/local/bin/app anon=1 dirty=1 N3=1 kernelpagesize_kB=4
3206000000 default file=/lib64/ld-2.12.so mapped=26 mapmax=6 N0=24 N3=2 kernelpagesize_kB=4
320621f000 default file=/lib64/ld-2.12.so anon=1 dirty=1 N3=1 kernelpagesize_kB=4
3206220000 default file=/lib64/ld-2.12.so anon=1 dirty=1 N3=1 kernelpagesize_kB=4
3206221000 default anon=1 dirty=1 N3=1 kernelpagesize_kB=4
3206800000 default file=/lib64/libc-2.12.so mapped=59 mapmax=21 active=55 N0=41 N3=18 kernelpagesize_kB=4
320698b000 default file=/lib64/libc-2.12.so
3206b8a000 default file=/lib64/libc-2.12.so anon=2 dirty=2 N3=2 kernelpagesize_kB=4
3206b8e000 default file=/lib64/libc-2.12.so anon=1 dirty=1 N3=1 kernelpagesize_kB=4
3206b8f000 default anon=3 dirty=3 active=1 N3=3 kernelpagesize_kB=4
7f4dc10a2000 default anon=3 dirty=3 N3=3 kernelpagesize_kB=4
7f4dc10b4000 default anon=2 dirty=2 active=1 N3=2 kernelpagesize_kB=4
7f4dc1200000 default file=/anon_hugepage\040(deleted) huge anon=1 dirty=1 N3=1 kernelpagesize_kB=2048
7fff335f0000 default stack anon=3 dirty=3 N3=3 kernelpagesize_kB=4
7fff3369d000 default mapped=1 mapmax=35 active=0 N3=1 kernelpagesize_kB=4
Where:
- "address" is the starting address for the mapping;
- "policy" reports the NUMA memory policy set for the mapping (see vm/numa_memory_policy.txt);
- "mapping details" summarizes mapping data such as mapping type, page usage counters, node locality page counters (N0
= node0, N1 =
node1, …) and the kernel page size, in KB, that is backing the mapping up.
19 /proc/PID/root
UNIX and Linux support the idea of a per-process root of the file system, set by the chroot(2) system call. This file is a symbolic link that points to the process's root directory, and behaves as exe, fd/*, etc. do.
In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3)).
20 /proc/PID/sched
TODO
21 /proc/PID/smaps
An extension based on maps, showing the memory consumption for each of the process's mappings. For each of mappings there is a series of lines such as the following:
08048000-080bc000 r-xp 00000000 03:02 13130 /bin/bash
Size: 1084 kB
Rss: 892 kB
Pss: 374 kB
Shared_Clean: 892 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 892 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd ex mr mw me dw
The first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping (size), the amount of the mapping that is currently resident in RAM (RSS), the process' proportional share of this mapping (PSS), the number of clean and dirty private pages in the mapping.
- The "proportional set size" (PSS) of a process is the count of pages it has in memory, where each page is divided by the number of processes sharing it. So if a process has 1000 pages all to itself, and 1000 shared with one other process, its PSS will be 1500. Note that even a page which is part of a MAP_SHARED mapping, but has only a single pte mapped, i.e. is currently used by only one process, is accounted as private and not as shared.
- "Referenced" indicates the amount of memory currently marked as referenced or accessed.
- "Anonymous" shows the amount of memory that does not belong to any file. Even a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE and a page is modified, the file page is replaced by a private anonymous copy.
- "AnonHugePages" shows the ammount of memory backed by transparent hugepage.
- "ShmemPmdMapped" shows the ammount of shared (shmem/tmpfs) memory backed by huge pages.
"Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by hugetlbfs page which is not counted in "RSS" or "PSS" field for historical reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field.
- "Swap" shows how much would-be-anonymous memory is also used, but out on swap. For shmem mappings, "Swap" includes also the size of the mapped (and not replaced by copy-on-write) part of the underlying shmem object out on swap.
- "SwapPss" shows proportional swap share of this mapping. Unlike "Swap", this does not take into account swapped out page of underlying shmem objects.
- "Locked" indicates whether the mapping is locked in memory or not.
- "VmFlags" field deserves a separate description. This member represents the kernel flags associated with the particular virtual memory area in two letter encoded manner.
The codes in "VmFlags" are the following: #+BEGIN_SRC sh rd - readable wr - writeable ex - executable sh - shared mr - may read mw - may write me - may execute ms - may share gd - stack segment growns down pf - pure PFN range dw - disabled write to the mapped file lo - pages are locked in memory io - memory mapped I/O area sr - sequential read advise provided rr - random read advise provided dc - do not copy area on fork de - do not expand area on remapping ac - area is accountable nr - swap space is not reserved for the area ht - area uses huge tlb pages ar - architecture specific flag dd - do not include area into core dump sd - soft-dirty flag mm - mixed map area hg - huge page advise flag nh - no-huge page advise flag mg - mergable advise flag #END_SRC Note that there is no guarantee that every flag and associated mnemonic will be present in all further kernel releases. Things get changed, the flags may be vanished or the reverse – new added.
This file is only present if the CONFIG_MMU kernel configuration option is enabled.
22 /proc/PID/stack
Report full stack trace, enable via CONFIG_STACKTRACE. The stack of PID's threads is in /proc/PID/task/TID/stack
23 /proc/PID/stat
Contains details information about the process itself. Contents of the stat files:
Field Content
pid process id
tcomm filename of the executable
state state (R is running, S is sleeping, D is sleeping in an uninterruptible wait, Z is zombie, T is traced or stopped)
ppid process id of the parent process
pgrp pgrp of the process
sid session id
tty_nr tty the process uses
tty_pgrp pgrp of the tty
flags task flags
min_flt number of minor faults
cmin_flt number of minor faults with child's
maj_flt number of major faults
cmaj_flt number of major faults with child's
utime user mode jiffies
stime kernel mode jiffies
cutime user mode jiffies with child's
cstime kernel mode jiffies with child's
priority priority level
nice nice level
num_threads number of threads
it_real_value(obsolete, always 0)
start_time time the process started after system boot
vsize virtual memory size
rss resident set memory size
rsslim current limit in bytes on the rss
start_code address above which program text can run
end_code address below which program text can run
start_stack address of the start of the main process stack
esp current value of ESP
eip current value of EIP
pending bitmap of pending signals
blocked bitmap of blocked signals
sigign bitmap of ignored signals
sigcatch bitmap of caught signals
0(place holder, used to be the wchan address, use /proc/PID/wchan instead)
0 (place holder)
0 (place holder)
exit_signal signal to send to parent thread on exit
task_cpu which CPU the task is scheduled on
rt_priority realtime priority
policy scheduling policy (man sched_setscheduler)
blkio_ticks time spent waiting for block IO
gtime guest time of the task in jiffies
cgtime guest time of the task children in jiffies
start_data address above which program data+bss is placed
end_data address below which program data+bss is placed
start_brk address above which program heap can be expanded with brk()
arg_start address above which program command line is placed
arg_end address below which program command line is placed
env_start address above which program environment is placed
env_end address below which program environment is placed
exit_code the thread's exit_code in the form reported by the waitpid system call
24 /proc/PID/statm
Provides information about memory usage, measured in pages. The columns are:
- size (1) total program size (same as VmSize in /proc/[pid]/status)
- resident (2) resident set size (same as VmRSS in /proc/[pid]/status)
- share (3) shared pages (i.e., backed by a file)
- text (4) text (code)
- lib (5) library (unused in Linux 2.6)
- data (6) data + stack
- dt (7) dirty pages (unused in Linux 2.6)
25 /proc/PID/status
Contains basic information about a process including its run state and memory usage.
Contents of the status files:
Field Content
Name filename of the executable
State state (R is running, S is sleeping, D is sleeping in an uninterruptible wait, Z is zombie, T is traced or stopped)
Tgid thread group ID
Ngid NUMA group ID (0 if none)
Pid process id
PPid process id of the parent process
TracerPid PID of process tracing this process (0 if not)
Uid Real, effective, saved set, and file system UIDs
Gid Real, effective, saved set, and file system GIDs
Umask file mode creation mask
FDSize number of file descriptor slots currently allocated
Groups supplementary group list
NStgid descendant namespace thread group ID hierarchy
NSpid descendant namespace process ID hierarchy
NSpgid descendant namespace process group ID hierarchy
NSsid descendant namespace session ID hierarchy
VmPeak peak virtual memory size
VmSize total program size
VmLck locked memory size
VmHWM peak resident set size ("high water mark")
VmRSS size of memory portions. It contains the three following parts (VmRSS = RssAnon + RssFile + RssShmem)
RssAnon size of resident anonymous memory
RssFile size of resident file mappings
RssShmem size of resident shmem memory (includes SysV shm, mapping of tmpfs and shared anonymous mappings)
VmData size of private data segments
VmStk size of stack segments
VmExe size of text segment
VmLib size of shared library code
VmPTE size of page table entries
VmPMD size of second level page tables
VmSwap amount of swap used by anonymous private data (shmem swap usage is not included)
HugetlbPages size of hugetlb memory portions
Threads number of threads
SigQ number of signals queued/max. number for queue
SigPnd bitmap of pending signals for the thread
ShdPnd bitmap of shared pending signals for the process
SigBlk bitmap of blocked signals
SigIgn bitmap of ignored signals
SigCgt bitmap of caught signals
CapInh bitmap of inheritable capabilities
CapPrm bitmap of permitted capabilities
CapEff bitmap of effective capabilities
CapBnd bitmap of capabilities bounding set
Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
Cpus_allowed mask of CPUs on which this process may run
Cpus_allowed_list Same as previous, but in "list format"
Mems_allowed mask of memory nodes allowed to this process
Mems_allowed_list Same as previous, but in "list format"
voluntary_ctxt_switches number of voluntary context switches
nonvoluntary_ctxt_switches number of non voluntary context switches
26 /proc/PID/syscall
TODO
27 /proc/PID/wchan
Present with CONFIG_KALLSYMS=y: it shows the kernel function symbol the task is blocked in - or "0" if not blocked.
28 /proc/PID/task
This is a directory that contains one subdirectory for each thread in the process. The name of each subdirectory is the numerical thread ID ([tid]) of the thread (see gettid(2)). Within each of these subdirectories, there is a set of files with the same names and contents as under the /proc/[pid] directories. For attributes that are shared by all threads, the contents for each of the files under the task/[tid] subdirectories will be the same as in the corresponding file in the parent /proc/[pid] directory (e.g., in a multithreaded process, all of the task/[tid]/cwd files will have the same value as the /proc/[pid]/cwd file in the parent directory, since all of the threads in a process share a working directory). For attributes that are distinct for each thread, the corresponding files under task/[tid] may have different values (e.g., various fields in each of the task/[tid]/status files may be different for each thread).
In a multithreaded process, the contents of the /proc/[pid]/task directory are not available if the main thread has already terminated (typically by calling pthread_exit(3)).
29 /proc/PID/fdinfo
A directory containing entries which describe the position and flags for each open file descriptor.
This file provides information associated with an opened file. The regular files have at least three fields – 'pos', 'flags' and mnt_id. The 'pos' represents the current offset of the opened file in decimal form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the file has been created with [see open(2) for details] and 'mnt_id' represents mount ID of the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo for details].
A typical output is
- pos:0
- flags:0100002
- mnt_id:19
All locks associated with a file descriptor are shown in its fdinfo too. lock: 1: FLOCK ADVISORY WRITE 359 00:13:11691 0 EOF The files such as eventfd, fsnotify, signalfd, epoll among the regular pos/flags pair provide additional information particular to the objects they represent.
Eventfd files ~~~~~~~~~~~
- pos:0
- flags:04002
- mnt_id:9
- eventfd-count:5a
where 'eventfd-count' is hex value of a counter.
Signalfd files ~~~~~~~~~~~~
- pos:0
- flags:04002
- mnt_id:9
- sigmask:0000000000000200
where 'sigmask' is hex value of the signal mask associated with a file.
Epoll files ~~~~~~~~~
- pos:0
- flags:02
- mnt_id:9
+tfd: 5 events: 1d data: ffffffffffffffff where 'tfd' is a target file descriptor number in decimal form, 'events' is events mask being watched and the 'data' is data associated with a target [see epoll(7) for more details].
Fsnotify files ~~~~~~~~~~~~
- pos:0
- flags:02000000
- inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d
where 'wd' is a watch descriptor in decimal form, ie a target file descriptor number, 'ino' and 'sdev' are inode and device where the target file resides and the 'mask' is the mask of events, all in hex form [see inotify(7) for more details].
If the kernel was built with exportfs support, the path to the target file is encoded as a file handle. The file handle is provided by three fields 'fhandle-bytes', 'fhandle-type' and 'f_handle', all in hex format. If the kernel is built without exportfs support the file handle won't be printed out. If there is no inotify mark attached yet the 'inotify' line will be omitted.
For fanotify files the format is
- pos:0
- flags:02
- mnt_id:9
- fanotify flags:10 event-flags:0
- fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003
- fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4
where fanotify 'flags' and 'event-flags' are values used in fanotify_init call, 'mnt_id' is the mount point identifier, 'mflags' is the value of flags associated with mark which are tracked separately from events mask. 'ino', 'sdev' are target inode and device, 'mask' is the events mask and 'ignored_mask' is the mask of events which are to be ignored. All in hex format. Incorporation of 'mflags', 'mask' and 'ignored_mask' does provide information about flags and mask used in fanotify_mark call [see fsnotify manpage for details]. While the first three lines are mandatory and always printed, the rest is optional and may be omitted if no marks created yet.
Timerfd files ~~~~~~~~~~~
- pos:0
- flags:02
- mnt_id:9
- clockid: 0
- ticks: 0
- settime flags: 01
- it_value: (0, 49406829)
- it_interval: (1, 0)
where 'clockid' is the clock type and 'ticks' is the number of the timer expirations that have occurred [see timerfd_create(2) for details]. 'settime flags' are flags in octal form been used to setup the timer [see timerfd_settime(2) for details]. 'it_value' is remaining time until the timer exiration. 'it_interval' is the interval for the timer. Note the timer might be set up with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' still exhibits timer's remaining time.
30 References:
1, https://en.wikipedia.org/wiki/Procfs#Linux
2, kernel sourcecode: ./Documentation/filesystems/proc.txt
stuff in /proc/PID/的更多相关文章
- Linux /proc/$pid部分内容详解
auxv /proc/[pid]/auxv包含传递给进程的ELF解释器信息,格式是每一项都是一个unsigned long长度的ID加上一个unsigned long长度的值.最后一项以连续的两个0x ...
- linux查看某个进程内存占用情况以及/proc/pid/status解释
以nginx 为例1.toptop -b -n 1 |grep nginx|awk '{print "VIRT:"$5,"RES:"$6,"cpu:& ...
- PROC系列之---/proc/pid/stat
转自: http://blog.csdn.net/zjl_1026_2001/article/details/2294067 /proc/ /stat 包含了所有CPU活跃的信息,该文件中的所有值 ...
- ps&&/proc/pid/xxx
ps 如果想看一个进程的启动时间,可以用lstart来看 [root@jiangyi02.sqa.zmf /home/ahao.mah] #ps -eo pid,lstart,etime,cmd |g ...
- How to translate virtual to physical addresses through /proc/pid/pagemap
墙外通道:http://fivelinesofcode.blogspot.com/2014/03/how-to-translate-virtual-to-physical.html I current ...
- /proc文件系统(二):/proc/<pid>/stat
0. 前言 /proc 文件系统是一个伪文件系统,它只存在内存当中,而不占用外存空间. 它以文件系统的方式为内核与进程提供通信的接口.用户和应用程序可以通过/proc得到系统的信息,并可以改变内核的某 ...
- Linux中 /proc/[pid] 目录各文件简析
Linux 内核提供了一种通过 proc 文件系统,在运行时访问内核内部数据结构.改变内核设置的机制.proc 文件系统是一个伪文件系统,它只存在内存当中,而不占用外存空间.它以文件系统的方式为访问系 ...
- 利用/proc/pid/pagemap将虚拟地址转换为物理地址
内核文档: Documentation/vm/pagemap.txt pagemap is a new (as of 2.6.25) set of interfaces in the kernel t ...
- netstat统计的tcp连接数与⁄proc⁄pid⁄fd下socket类型fd数量不一致的分析
最近,线上一个应用,发现socket数缓慢增长,并且不回收,超过警告线之后,被运维监控自动重启了. 首先到zabbix上观察JVM历史记录,发现JVM-Perm space最近两周没有数据,猜测是程序 ...
随机推荐
- Python 通过打码平台实现验证码
在爬虫时,经常遇到登录需要验证码的情况,简单的验证码可以自己解决,复制的验证码需要借助机器学习,有一定的难度.还有一个简单的方案就是采用付费的打码平台. 比如R若快(http://www.ruokua ...
- 【Java】Springboot-Quartz-分布式任务调度
Springboot-Quartz-分布式任务调度 springboot 调度 自定义并发_百度搜索 spring-boot @Async 的使用.自定义Executor的配置方法 - CSDN博客 ...
- "garbage at end of line" on Windows 10
在windows 10上运行docker-machine scp myvm1 docker-compose.yml myvm1:~的时候报错: "garbage at end of li ...
- [Functional Programming] Using Last monoid with Maybe
Imaging we have a deck of cards, eveytimes we need to pick one card from deck, the result we want to ...
- [Git] Undo a commit that has already been pushed to the remote repository
If we pushed our changes already to the remote repository we have to pay attention to not change the ...
- 大量带BPM的跑步歌曲/跑步音乐下载
20150110停止更新告知:不知不觉本帖更新有近半年了.从最开始跑步已经四年多,一直是听着音乐跑的,音乐支持.陪伴.丰富着我的跑步之旅.直到上个月因一次觉得音乐吵,我开始有意地摘掉耳机去跑步,并开始 ...
- Android开发——Android M(6.0) 权限解决方案
Android开发--Android M(6.0) 权限解决方案 自从Android M(6.0)发布以来,权限管理相比以前有了很大的改变,很多程序员发现之前运行的好好的Android应用在Andro ...
- 【iOS开发】如何用 Swift 语言进行LBS应用的开发?
本文分为三部分,第一部分详解用Swift语言开发LBS应用,并给出完整的示例与源代码:第二部分介绍如何申请LBS密钥,第三部分是综合示例查看,扫描二维码即可查看示例demo. 第一部分 使用Swift ...
- FIS前端集成解决方案
FIS前端集成解决方案-文档结构 什么是FIS 部署FIS FIS基本使用 模块定义 加载方式 调用Tangram 2.0 FIS开发实例 --附件下载-- 什么是FIS FIS提供了一套贯穿开发流程 ...
- Binary Search二分法搜索C++程序
二分法基本上学计算机的都听过,但是有人不知道的就是其实二分法是减治法的思想. 所谓减治法和分治法有一个主要差别就是减治法是减去一般,就是分治之后只需要解决原问题的一半就可以了得到全局问题的解了.所以速 ...