Tag Info

Hot answers tagged

60

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


49

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


46

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


26

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


25

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


20

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


16

On Linux at least, you can also do: ps -o lstart= -p the-pid to have a more useful start time. The mtimes of the files in /proc on Linux (at least) are generally the date when those files were instantiated, which would be the first time something tried to access them or list the directory content. For instance: $ sh -c 'date +%T.%N; sleep 3; echo ...


16

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


15

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


14

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


12

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


11

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


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

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


11

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.


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

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.


10

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.


10

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


9

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


9

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.


9

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


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


8

Parse the root= parameter from /proc/cmdline.


8

Read this blog post: Solving problems with proc There are a few tips what you can do with the proc filesystem. Among other things, there is a tip how to get back a deleted disk image or how to staying ahead of the OOM killer. Don't forget to read the comments, there are good tips, too.


8

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


8

From the T520's specs: Intel® Core™ i5-2520M processor (dual-core, 2.50GHz, 3MB Cache), The i5-2520M has 2 cores + hyper threading, for a total of 4 cores seen by the system.


8

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


8

In bash you can do the following. This will work for all possible contents of the variables and avoids eval: while IFS= read -rd '' var; do declare +x "$var"; done </proc/$PID/environ This will declare the read variables as shell variables in the running shell. To export the variables into the running shell environment instead: while IFS= read -rd '' ...


7

There is the grsecurity patchset (included in SELinux, but doesn't have the latter's horribly complicated MAC permission system) for the Linux kernel which offers the option of allowing only the owner (and root) to see his/her processes. It also offers other goodies without being as intrusive as SELinux. A similar option is there on Solaris, or so I heard.



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