Tag Info

Hot answers tagged

77

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


55

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


52

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


35

check with lsof 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


29

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


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


22

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


21

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


19

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


18

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


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


16

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


15

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.


15

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


13

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//fd/ that cooresponds to the filehandle ls -l ...


13

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


13

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.


11

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


11

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.


11

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


11

This is likely to be a thread. In Linux, threads have a different process ID to the other threads in the process. When you look at the PID column in ps, you're actually looking at the thread group ID (TGID), which is common amongst all threads in a process. This is for historical reasons due to the way threads evolved in Linux. For example, on my system, ...


11

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


10

On the systems I've looked at, /dev/root is a symlink to the real device, so readlink /dev/root (or readlink -f /dev/root if you want the full path), will do it.


10

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.


10

Check the kernel documentation for information about files in /proc. There is one such file per process because not all processes see the same mount points. Chroot is a traditional Unix feature that makes it possible to restrict processes to a subtree of the filesystem tree. A chrooted process would not see mount points outside its root. Linux takes this ...


10

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


9

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


9

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


9

This is normal behavior under OS-level virtualization. This can only be executed by someone with root access to the hardware node. With for example OpenVZ, you don't get your own kernel instance and as such, are restricted from performing commands like this. All share the same page cache, so to drop caches of only your instance, the kernel must check if ...


9

In this answer, I assume a system where /proc/$pid/environ returns the environment of the process with the specified PID, with null bytes between variable definitions. (So Linux, Cygwin or Solaris (?)). Zsh export "${(@ps:\000:)$(</proc/$pid/environ)}" (Pretty simple as zsh goes: an input redirection with no command <FILE is equivalent to cat FILE. ...



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