Hot answers tagged proc
41
/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 ...
24
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 ...
19
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
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. :-)
10
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 ...
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
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 ...
10
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 ...
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
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.
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, ...
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, ...
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.
7
You can run the mount without any arguments to get a list of current mounts. The /etc/mtab file should have similar data, but like you said it is possible for this to be inconsistent with what is actually mounted in the event that the /etc file system is messed up, not writable, or another program has messed with it. You can get specific information about ...
7
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.
7
I don't know of a way of adding things to /proc outside of writing a module (or plain kernel code). Might be some utilities out there though.
If you can build and insert a module, then it's pretty simple: you can just create another symlink (/proc/mounts is a symlink already).
Source (mnt_link.c):
#include <linux/module.h>
#include ...
6
Use either skill -u UID or pkill -u UID.
Skill was a linux-specific and is now outdated, and pkill is more portable (Linux, Solaris, BSD)
I think, both utilites have no access to any list other than full list of processes (or readdir of /proc). I think, they itterate over /proc and check every process for match.
PS: Another tool is killall .
To get list ...
6
For sockets, you can find the inode number in /proc/net/tcp and /proc/net/udp. For example:
lrwx------ 1 root root 64 May 26 22:03 3 -> socket:[53710569]
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
155: 0100007F:001B 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 ...
6
The easiest way to do it would be to change the binary:
sed s-/proc/mtd-/tmp/mntx- < romdump > romdump.new
ln -s /proc/mounts /tmp/mntx
./romdump.new
The trick here, since you're editing a binary, is to make sure the original string /proc/mtd is the same length as the new string /tmp/mntx, so that you don't change the size or location of anything in ...
6
proc is a virtual file system so I wouldn't rely on any file status information.
The start time of the process is located at /proc/PID/stat column 22. It is given in jiffies after system boot. To convert it to seconds you have to divide it by sysconf(_SC_CLK_TCK) which is 100 for most systems (but not all!).
To get the time of system boot you determine the ...
5
I'm assuming the files in /proc that youre saying are owned by UID=1000 the the ones like /proc/12345 (just number directories)? These are process accounting directories, the UID is set to that of the user running the program associated with that directory. If you launch a program with pid '12345' then /proc/12345 will be owned by your user.
I doubt a chown ...
5
The /proc filesystem is a so-called "pseudo filesystem", meaning that (afaiu) there is no disk usage.
I'm not quite sure how this works at the lowest level, so I may be wrong, but here goes. If I run
f = open('/proc/meminfo')
f.read()
f.seek(0)
f.read()
I get two different outputs. Afaik, seek(0) only resets the read offset and it doesn't re-open the ...
5
Files in /proc are not stored on a disk, they are generated on the fly by the kernel. See What happens when I open and read from /proc?
If you're programmatically inclined, you can read the implementation of /proc in the kernel source code. The contents of the /proc/self symbolic link is generated by a function that fills a buffer with the pid of the ...
4
If you disable /proc, a lot of things will stop working. Not only will you not be able to use ps and company, even to see your own processes, but a lot of tools and services will not be able to run. Looking at the computer I'm writing this on, processes that have a file under /proc open include mdadm (RAID), Xorg (GUI), hald (hotpluggable devices), acpid ...
4
The files are not stored on disk, but they are hooks to the kernel.
When you open a file (using fopen()), the kernel handles this job. It walks through the mountpoints, finds the apropriate driver to handle the request, and hands the task to that driver.
In the case of /proc, the file read request is passed to the internal "proc" system in the kernel. At ...
4
ptrace's interface allows you to read only one word at a time, and I'm trying to scan a larger portions of the stack
Well, just use a loop, then. I honestly don't see how that constitutes a problem with ptrace, I use it all the time to remotely access processes.
I use something like this:
static int memcpy_from_target(pid_t pid, char *dest, long src, ...
4
You cannot and must not copy files in /proc, or /sys. Generally speaking, you need to arrange to copy only the disk-backed files.
The files under /proc and /sys are generated by the kernel on the fly when you read them. Their contents provides information about the running system. For example, /proc/1234 is a directory where you can read information about ...
4
The traditional way to log and track user CPU time is process accounting. On Linux, install the GNU accounting utilities, typically provided by a package called acct. I'm not sure how accurate it will be at keeping track of the time spent in very short-lived processes, but it'll at least list all the processes ever executed.
Run lastcomm to get a list of ...
3
You can't assume that, process ids (and thread ids) can be reused, so the ordering is not guaranteed. (That's not likely on a freshly booted 64bit system, but you'll see it on machines with large uptimes.)
You can get the thread group id (which is the process id) from the /proc/${id}/status. It's in the line Tgid: nnnnn.
Ex:
$ cat /proc/8288/status
Name: ...
Only top voted, non community-wiki answers of a minimum length are eligible
