In the beginning (way back in Unix), the way that programs found out about the running processes on the system was via directly reading process structures from the kernel memory (opening /dev/mem, and interpreting the raw data directly). This is how the very first 'ps' commands worked. Over time, some information was made available via system calls.
Whenever you read a file under /proc, this invokes some code in the kernel which computes the text to read as the file content. The fact that the content is generated on the fly explains why almost all files have their time reported as now and their size reported as 0 — here you should read 0 as “don't know”. Unlike usual filesystems, the filesystem which is ...
This has nothing to do with foreground and background processes; it only has to do with the currently running process. When the kernel has to answer the question “What does /proc/self point to?”, it simply picks the currently-scheduled pid, i.e. the currently running process (on the current logical CPU). The effect is that /proc/self always points to the ...
When trying to gain insight into what sort of magic is happening behind the scenes your best friend is strace. Learning to operate this tool is one of the best things you can do to get a better appreciation for what crazy magic is happening behind the scenes.
$ strace -s 200 -m strace.log cat /proc/cpuinfo
read(3, "processor\t: 0\nvendor_id\t: ...
The information that you read from the proc filesystem is not stored on any media (not even in RAM), so there is nothing to update.
The purpose of the proc file system is to allow userspace programs to obtain or set kernel data using the simple and familiar file system semantics (open, close, read, write, lseek), even though the data that is read or written ...
On Linux at least, you can also do:
ps -o lstart= -p the-pid
to have a more useful start time.
Note however that it's the time the process was started, not necessarily the time the command that it is currently executing was invoked. Processes can (and generally do) run more than one command in their lifetime. And commands sometimes spawn other processes.
A good option might be lsof. As man lsof states it is handy for obtaining information about open files such as Internet sockets or Unix Domain sockets.
At first, get an overview about /proc/$PID/fd/ and the listed socket numbers.
For example, socket: might interest you.
Then use lsof -i -a -p $PID to print a list of all ...
Use lsof to find the deleted, but open, file still consuming space:
lsof | grep deleted | grep etilqs_1IlrBRwsveCCxId
chrome 3446 user 128u REG 253,2 16400 2364626 /var/tmp/etilqs_1IlrBRwsveCCxId (deleted)
Find the entry in /proc/<pid>/fd/ that cooresponds to the filehandle:
ls -l /proc/3446/fd/...
I've found the answer while still writing the question. I've decided to post it anyway because others may find this insightful, and then answer it myself; I hope this is not frowned upon :)
The user Philipp Matthias Hahn on the linux-kernel mailing list has figured it out at least partially:
As far as I researched for IPv4 some time ago, the "default" ...
The one that accesses the symlink (calls readlink() on it, or open() on a path through it). It would be running on the CPU at the time, but that's not relevant. A multiprocessor system could have several processes on the CPU simultaneously.
Foreground and background processes are mostly a shell construct, and there's no unique foreground process either, ...
For sockets you can find more information about the inode in /proc/net/tcp, /proc/net/udp or /proc/net/unix. For example:
ls -l /proc/<pid>/fd
lrwx------ 1 root root 64 May 26 22:03 3 -> socket:
We see inode is 53710569.
head -n1 < tcp ; grep -a 53710569 tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt ...
The problem is that those /proc files on Linux appear as text files as far as stat()/fstat() is concerned, but do not behave as such.
Because it's dynamic data, you can only do one read() system call on them (for some of them at least). Doing more than one could get you two chunks of two different contents, so instead it seems a second read() on them just ...
I am logged in as root over SSH...It is a remote machine running Debian.
Is it actually a remote machine, or a just a remote system? If this is a VPS slice somewhere, (at least some forms of) OS virtualization (e.g. openVZ) won't permit this from within the container. You don't run the machine, you just run your slice.
The /proc/PID/fd/NUM symlinks are quasi-universal on Linux, but they don't exist anywhere else (except on Cygwin which emulates them). /proc/PID/fd/NUM also exist on AIX and Solaris, but they aren't symlinks. Portably, to get information about open files, install lsof.
Unices with /proc/PID/fd
Under Linux, /proc/PID/fd/NUM is a slightly magic ...
The wording could have been better but then again any wording you try to compose to express the idea of self reference is going to be confusing. The name of the directory is more descriptive in my opinion.
Basically, /proc/self/ represents the process that's reading /proc/self/. So if you try to open /proc/self/ from a C program then it represents that ...
/proc is a filesystem because user processes can navigate through it with familiar system calls and library calls, like opendir(), readdir(), chdir() and getcwd(). Even open(), read() and close() work on a lot of the "files" that appear in /proc. For most intents and almost all purposes, /proc is a filesystem, despite the fact that its files don’t occupy ...
If /proc is only the proc mount (and no one is playing tricks with overlays), no, a pid-based folder only exists as long as the corresponding process exists in some state (including as a zombie). In fact, just before returning a directory entry for a process id, the kernel re-validates the process’ existence — so at the instant a directory entry is returned, ...
It is updated on every access. You see the state of the kernel in that moment. That's why the size shown for the "files" is not the real size. The real size can change and is determined the moment you access the file.
You could say, it may be not updated for days. If you don't look at it. :-)
You can look at field 5th in output of /proc/[pid]/stat.
$ ps -ejH | grep firefox
3043 2683 2683 ? 00:00:21 firefox
$ < /proc/3043/stat sed -n '$s/.*) [^ ]* [^ ]* \([^ ]*\).*/\1/p'
From man proc:
Status information about the process. This is used by ps(1). It is defined in /usr/src/linux/fs/proc/array....
The following will convert each environment variable into an export statement, properly quoted for reading into a shell (because LS_COLORS, for example, is likely to have semicolons in it), then sources it.
[The printf in /usr/bin, unfortunately, generally doesn't support %q, so we need to call the one built into bash.]
. <(xargs -0 bash -c 'printf "...
Under the /proc directory, you can also find the IPv4 addresses in the Forwarding Information Base table, at /proc/net/fib_trie
The table is pretty intelligible doing a mere cat, first comes the Main: and then Local:
or to see your network, IP addresses and netmask:
cat /proc/net/fib_trie | grep "|--" | egrep -v "0.0.0.0| 127."
It represent the bitmask for events supported by the device.
Sample of devices entry for a AT Keyboard:
I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
H: Handlers=sysrq kbd event2
B: KEY=20000 200 20 ...
I can read the /proc/$PID/net/tcp file for example and get information about TCP ports opened by the process.
That file is not a list of tcp ports opened by the process. It is a list of all open tcp ports in the current network namespace, and for processes running in the same network namespace is identical to the contents of /proc/net/tcp.
To find ports ...
The intent of the “bugs” field in /proc/cpuinfo is described in the commit message which introduced it:
x86/cpufeature: Add bug flags to /proc/cpuinfo
Dump the flags which denote we have detected and/or have applied bug
workarounds to the CPU we're executing on, in a similar manner to the
The advantage is that those are not ...
If you want to limit yourself to ELF detection, you can read the ELF header of /proc/$PID/exe yourself. It's quite trivial: if the 5th byte in the file is 1, it's a 32-bit binary. If it's 2, it's 64-bit. For added sanity checking:
If the first 5 bytes are 0x7f, "ELF", 1: it's a 32 bit ELF binary.
If the first 5 bytes are 0x7f, "ELF", 2: it's a 64 bit ELF ...
http://lxr.linux.no/linux+v3.2.9/fs/proc/base.c#L2482 is the current implementation.
The proc filesystem is entirely virtual, and is implemented so the internal VFS readlink delegates to the right place for special symlinks. So, it calculates what self points to when it is read / traversed, not every context switch.
The perl function kill(0,$pid) can be used.
If the return code is 1 then the PID exists and you're allowed to send a signal to it.
If the return code is 0 then you need to check $!. It may be EPERM (permission denied) which means the process exists or ESRCH in which case the process doesn't exist.
If your checking code is running as root then you can ...