Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I want to view a status of a process among 2000 processes, Without using top and ps
commands.
The name of the process is tom.
A process don't have any name (only the program it is running has one, but see also pthread_setname_np(3)... you might have pathological cases like this). It has a pid (which is some integer number, like 1234, of type pid_t). See credentials(7) and fork(2) and execve(2). Use pidof(1) and pgrep(1) to find the pid of some process. An executable program (e.g. /bin/bash) can be run by several processes (or none, or only one).
You may use kill(2) with a zero signal number to check that the process exists.
Most importantly, you should consider using /proc/ (see proc(5) for more). For the process of pid 1234, see /proc/1234/ which has several files and subdirectories (notably /proc/1234/status and /proc/1234/maps). Try cat /proc/$$/status and cat /proc/$$/maps and stat /proc/$$/exe and ls -l /proc/$$/ in a terminal (then replace $$ by whatever pid is interesting for you).
The top and ps utilities (and also pidof, pgrep, ...) are using that /proc/ (which is the mean by which the Linux kernel shows information on processes, and on the system itself). And you can write your program (or script) doing that too and using /proc/. See also this.
From inside a program, you can explore /proc/ like you would explore other file trees, e.g. using stat(2), opendir(3), readdir(3), nftw(3) etc.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
Improve this question
I'm having trouble finding them, and how to use them in general. for example i see in x86 functions, the output may be a file descriptor. i cant seem to find much about them on the web so im trying it here. and yes im very new to linux
The list of file descriptors is:
ls -l /proc/self/fd
Every process has its own list.
The following script will print all file descriptors of all processes.
#! /bin/bash
find /proc -maxdepth 1 -type d -regex '/proc/[0-9]+' -printf '%P\n' |
{
while read -r pid; do
if [[ -d /proc/$pid ]]; then
printf '%d:' "$pid"
find /proc/"$pid"/fd -type l -printf ' %P' 2>/dev/null
printf '\n'
fi
done
}
You need root permissions to execute it.
A file descriptor is basically just an integer. It gets returned by certain functions, e.g. open().
It is used very similar to a pointer in C, you don't do much with it except pass it to other functions, e.g. read(). I don't think doing pointer arithmetic on file handles makes that much sense, though. The fstat() system call will return you a bunch of information about the file. See the manpage:
man 2 fstat
Each process has its own list of file handles, the numbering always starts at 0 for STDIN, 1 for STDOUT and 2 for STDERR, then continues simply counting up as you open and close files.
Except for the first three, that number has no deeper meaning, it just tells the kernel which one from its list of open files it should operate on. The concept seems to be so simple that nobody has bothered to document it... ;-)
Is there a list of linux file descriptors somewhere?
Yes, the kernel maintains a list of open file descriptors per process. This is the reason you don't find it in internet (it is very dynamic). The ones a process always receives already open, when the program starts are: 0 (standard input); 1 (standard output); and 2 (standard error). This is the mechanism employed in unix systems to allow the parent process to redirect standard input, standard output or standard error. Other file descriptor numbers are assigned/created by the kernel when you open() a file, create a socket with socket() system call, pipe() system call, or some other way (there are many)
A file descriptor per se is just a unique number (each process has a set of distinct numbers) the kernel uses to convey with the process a reference to a kernel resource (like a name) that the program is going to use. When you open() a file, you provide a name and the way you are going to access it (read only, read/write, write only or none -- this last to deal with resources that don't allow you to read/write them, like directories or the like) and receive in exchange a descriptor number that will be used in all the calls related to that file/socket/etc.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
according to wikipedia
In computing, a process is an instance of a computer program that is being executed. It contains the program code and its current activity. Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently.
according to this definition a kernel should be a process?
A kernel is bigger than a process. It creates and manages processes. A kernel is the base of an operating System to make it possible to work with processes.
Kernel is a comprehensive/complex process, that handles all other tasks(threads) in both kernel and user space
Kernel's PID is 0, and that triggers all other processes(Kernel/User), directly(children) and indirectly(child handling other subsequent children).
Kernel runs the scheduler, which is the core part of task/process management.
To see the kernel Processes that are spawned by kernel
ps -caefL | grep -v grep | grep "\[\|PPID" | grep root
to see the user space processes,
ps -caefL | grep -v grep | grep -v "\["
You will not be able to see the line of 0th PID, which is the kernel(the driving force)
Good to say that kernel is, "device driver for the CPU"
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Being a super user , I executed the following command on linux
rm rm
which removes itself. Because when process is in execution , its reference count
is not zero.Hence it cannot be deleted. So I am bemused,
how and why does it happen?
I tried the same with chown 0000 chown as well.
cp -r Dir1/ Dir2/
In above command also , what happens when i delete the source directory only when copying is in progress???
It is the same as for temporary files.
Recall that a usual way to create some temporary file is to open(2) a file (keeping its file descriptor), then unlink(2) (while still having an open file descriptor). Then the data of the file remains in the file system as long as the process is running and have not close(2)-d that file descriptor.
This is because files really are inodes -not file names in directories. (directories contain entries associating names to inodes).
The kernel manages the set of "used" (or "opened") inodes, and that set contains the inodes executed by processes (actually, the inodes involved in some address mapping like thru mmap(2) or execve(2))
So just after /bin/rm /bin/rm starts, the kernel has one reference to rm binary as the executable of the process.
When it processes the unlink syscall, it has temporarily two references (one being the process in execution, the other the path /bin/rm passed to unlink kernel implementation) and decreases it to one.
Of course you should avoid typing /bin/rm /bin/rm but then you usually have some standalone shell like sash to be able to repair your system.
On Windows, "rm rm" is probably not possible, because of the reference count you mentioned. On most *nix systems however, it is. "rm" and also "chmod" is loaded into memory and only then will execute whatever the commandline specified. Another example: edit a file in one window and while editing that file, remove it in another window. That too should be possible on most *nix systems, regardless of reference counts.
You cant delete a directory using rm until its empty..
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
In the /proc file system, why is that some files have their maps file empty. Is it because no memory has been allocated to them or the data isn't available?
They must be allocated some memory, otherwise how are they running?
First, notice that all the pseudo-files /proc/1234/maps and /proc/self/maps have always a zero size, as reported by the stat(2) syscall and the ls command. However, they are sequentially readable (e.g. by the cat command, or with read(2) syscall, e.g. called by fgets). Try cat /proc/self/maps and ls -ls /proc/self/maps for example.
A probable reason for the /proc/*/maps files to have a 0 size is that computing their size means computing their content, and that could be expensive. So the kernel prefers to say 0 for their size. Think of them as being sort of pipes. You need to read them sequentially, they are not lseek(2)-able.
Read the proc(5) man page for details about /proc/; notice that it is using Unix permissions and ownership, so you cannot access a /proc/1234 directory if the process of pid 1234 is not yours.
And you might also have some zombie processes. These don't have any address space anymore, so I won't be surprised if their maps pseudo-file in /proc is truly empty (in the sense that reading it gives immediately an end-of-file condition), or even missing.
Remember that files under /proc are pseudo-files, in the sense that the kernel is providing them (and giving their data), and they don't involve any real disk I/O. In particular, reading them should be fast.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
What are the processes that write to "/var/adm/messages"?
From what I gathered Syslogd does the job. Am i right?
Also I saw multiple files, messages, messages.0, messages.1 and so on. Why is it so?
Also is there any other system process that writes to these files?
Any help is highly appreciated.
Yes, processes that use the syslog framework send messages to syslogd, which reads /etc/syslog.conf to determine where (or if) the message should be written based on the facility and level of the message. For example, if syslog.conf has the entry
user.debug /var/log/mylog
then all messages of a higher level than debug (the lowest level) from processes of the user facility (i.e. non-system processes) will be sent to /var/log/mylog (man syslog.conf for full explanation including possible facilities and levels).
The /var/adm/messages.X files are created as /var/adm/messages is rotated by the logadm cron job (again, see the man pages for logadm and logadm.conf).
NOTE: This answer is based on Solaris experience; file locations and behavior may vary with other *NIX flavors.
You can find out yourself with dtrace:
http://dtracebook.com/index.php/File_Systems
Syscall write(2) by file name: dtrace -n 'syscall::write:entry {
#[fds[arg0].fi_pathname] = count(); }'