Hot answers tagged

94

/proc/$pid/maps /proc/$pid/mem shows the contents of $pid's memory mapped the same way as in the process, i.e., the byte at offset x in the pseudo-file is the same as the byte at address x in the process. If an address is unmapped in the process, reading from the corresponding offset in the file returns EIO (Input/output error). For example, since the first ...


58

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


56

Check with lsof to see if there are files held open. Space will not be freed until they are closed. sudo /usr/sbin/lsof | grep deleted will tell you which deleted files are still held open.


54

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


41

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


35

What is the difference between procfs and sysfs? proc is the old one, it is more or less without rules and structure. And at some point it was decided that proc was a little too chaotic and a new way was needed. Then sysfs was created, and the new stuff that was added was put into sysfs like device information. So in some sense they do the same, but ...


35

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


31

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


27

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


25

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:[53710569] 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 ...


24

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


23

That's the inode number for the pipe or socket in question. A pipe is a unidirectional channel, with a write end and a read end. In your example, it looks like FD 5 and FD 6 are talking to each other, since the inode numbers are the same. (Maybe not, though. See below.) More common than seeing a program talking to itself over a pipe is a pair of separate ...


22

The documentation for Linux's implementation of /proc is in Documentation/filesystems/proc.txt in the kernel documentation. Beware that /proc is one of the areas where *ixes differ most. It started out as a System V specific feature, was then greatly extended by Linux, and is now in the process of being deprecated by things like /sys. The BSDs — ...


22

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. :-)


22

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


21

This command (from gdb) dumps memory reliably: gcore pid Dumps can be large, use -o outfile if your current directory doesn't have enough room.


18

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


17

it's just an area of files containing information But that's exactly what a filesystem is. Filesystems don't have to be writable and they don't have to reside on permanent storage. Note: There's a distinction between procfs (the pseudo filesystem implementation in the kernel) and its conventional mount point /proc. You could in theory mount a procfs ...


17

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


16

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


15

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.


15

You can't do this without a nasty hacks - there's no API for this, no way to notify the process that its environment has changed (since that's not really possible anyway). Even if you do manage to do that, there is no way to be sure that it will have any effect - the process could very well have cached the environment variable you're trying to poke (since ...


15

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.


14

The file in /proc/<pid>/io represent what you need. It's a bit scripting work to get an output similar to iotop. See the linux kernel documentation to the /proc/<pid>/io file values: 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 ...


13

When you read from /proc, the kernel generates content on the fly. There is no hard drive involved. What you're doing is similar to what any number of monitoring programs do, so I advise you to look at what they're doing. For example, you can see what top does: strace top >/dev/null The trace shows that top opens /proc/uptime, /proc/loadavg, /proc/...


12

/proc and (usually) much of /dev are read only kernel-generated "filesystems". You don't delete them, you just umount the filesystem. If rm -r /proc/6352 worked, it would have to be semantically equivalent to kill -9 6352, since it's really just presenting information about pid 6352, not actual files anywhere. Use mount to see what mounted filesystems are ...


12

The answer given by @slm is very comprehensive, but I think a simpler explanation might come from a change in perspective. In day-to-day usage we can think of files as physical things, ie. chunks of data stored on some device. This makes files like /proc/cpuinfo very mysterious and confusing. However, it all makes perfect sense if we think of files as an ...


12

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 Linux Under Linux, /proc/PID/fd/NUM is a slightly magic ...


12

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' 2683 From man proc: /proc/[pid]/stat Status information about the process. This is used by ps(1). It is defined in /usr/src/linux/fs/proc/array....


11

You can look into the documentation which comes with the kernel source. (possibly greping for proc/sys ...). Located at Documentation/filesystems: proc.txt and sysfs.txt.



Only top voted, non community-wiki answers of a minimum length are eligible