Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
man for int kill(pid_t pid, int sig); says:
If pid equals -1, then sig is sent to every process for which the
calling process has permission to send signals, except for process 1
(init), but see below.
Does this mean that if my program is run with root permissions and it accidentally (due to memory corruption or a hack) provides -1 as pid argument - this will cause a complete DoS for the entire system?
If so, is it recommended to always perform a double check for the pid argument value before calling this potentially disasterous call? (just sayin')
Does this mean that if my program is run with root permissions and it
accidentally (due to memory corruption or a hack) provides -1 as pid
argument - this will cause a complete DoS for the entire system?
Yes, such a scenario is possible. But the chances of it happening is very less. Because no program that run with root permissions would do such a thing. If a malicious user/binary has somehow got gained root privilege, then sending signals is just one of the problems.
If so, is it recommended to always perform a double check for the pid
argument value before calling this potentially disastrous call?
That's just super paranoid thinking. There are thousands of ways to do disastrous activities.You might as well worry about:
What if there's not malicious daemon, ran at system startup, does:
kill(-1, SIGKILL);
How do you know if library function you make wouldn't call reboot(2) and reboot your system?
etc.
Besides, PIDs are not just user provided values that need to be sanitized. PIDs are mostly values acquired within the program using system calls or library calls. So the chances of "accidentally" using -1 is zero. Basically, you someone/program has root privilege and decided to screw your system then there's not much you can do.
Related
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 6 years ago.
Improve this question
As we know that exec family function calls eventually calls execve() which is a system call and remaining are library functions. So, typically, whatever implications applies on execve() are true for other exec*() functions as well.
I would like to know if, during execution of execve(), all signals are blocked until it succeed, or if there is a way to pass signal to that pid which corresponds to exec? (I know it does not return on success and further execution of calling function does not happen)
I am not sure I got your question right, so feel free to correct me if I am wrong.
But, basically, yes, system calls can be considered as 'atomic' from the process point of view. So, once the execve() system call is started, only the kernel has the hand on it and it won't release the process until running the new command or failing with an error code or raise the SIGKILL signal (as SIGKILL is the only unblockable signal).
But, once the execve() spawned a new process (and returned from the kernel), it is perfectly interruptible with any signal.
This question already has answers here:
How to detect the launching of programs on Linux?
(8 answers)
Closed 7 years ago.
I am writing a C program that runs in the background of the Linux shell and if the total memory consumption is over 85% of the total memory, then it will print out a warning. What would be the best way to check if a new process was created (I want to check the values for the memory every time a process is created)?
The most effective way of determining when processes are created (and exit) will be to use the proc connector. It's somewhat complex to use, but will notify your process immediately when events occur.
However, keep in mind that the memory usage of processes can change dramatically while they are running. Monitoring for processes being created is almost certainly not going to be sufficient for your needs; you will need to poll memory usage periodically. (There is no general way to get notifications for system memory usage, short of running your processes in a cgroup with a memory controller and registering an OOM handler. You don't want to do this.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
How do i know that a process [not called by c] has exited and based on that do something in C?
For eg. there is a running application , say notepad. I create an application to delete the text file created by it. I cannot do that while it is open . So how do I know when notepad exits and based on that take a decision in C.,.,
If you know the PID of the process, you can use the kill() function. Sending signal 0 to the process is guaranteed not to kill it, but merely to report on whether it is running.
If you don't know the PID of the process, there is often a pidfile on disk for the process concerned (e.g. /var/run/processname.pid) - look at the file that starts it for more information. If this PID file is not there, the process should not be running. If it is there, the file contains (as text) the PID of the process, which you can check using the method above.
If you do not know the PID of the process and it does not have a PID file, then you will have to walk /proc, or shell out to pgrep or similar. Avoid this if possible.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Improve this question
I have this question how to a write a C program that creates 3 child processes which read from 3 different files and write to the parent process using pipes.
Each child should wait a random amount of time (3 -10 seconds) between writing each 50 characters.
The father should read from pipes and
write everything he gets (from all 3 files) into one new file.
To expand on the answer by Rachit Jain, you could create an array with the filenames, and use the loop counter as an index into the array to know which file each child process should open. Works best when each child process should process the files the same, just do it in parallel.
As for the pipes, you really need three different pipes, one per child process, or the data from the children might become mixed. Use e.g. select or poll to check for input from the different pipes.
Read Advanced Linux Programming first.
You first need to create the 3 pipes with the pipe(2) syscall (repeated 3 times).
You then need to create the 3 child processes with the fork(2) syscall. Handle the 3 possible return values of fork: <0 on failure, ==0 in child, >0 in parent. Remember the pid_t in parent. In each child call dup2(2) to have the STDOUT_FILENO be the output of relevant pipe.
At last, in the parent, make a simplistic event loop, using the poll(2) multiplexing syscall to find out which pipe should be read(2)
Use sleep(3) and random(3) in the child, but don't forget to seed -using srand- the PRNG with something random (like its pid gotten by getpid(2) added to the current time(2)....; or use /dev/urandom see urandom(4))
As Jonathan Leffler commented, since 3*50 is less than PIPE_MAX, you might perhaps use a single pipe. I feel that using an event loop is more safe and more general (it will work if you replace 50 by 500000 which is greater than PIPE_MAX).
I don't think I want or have time to do more of your homework for you. I gave you enough hints above.
I believe that Federos Koros fedoroskoros#gmail.com is very wrong in trying to pay someone to do his homework, and I did sent him a private email about that. The question is now deleted.
fork () three times in a loop with a variable ,say i, and below put conditions for i=0 , i=1 and i=2. in each each condition read one of your file.
rest won't be tough task either now.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Linux API to list running processes?
How can I detect hung processes in Linux using C?
Under linux the way to do this is by examining the contents of /proc/[PID]/* a good one-stop location would be /proc/*/status. Its first two lines are:
Name: [program name]
State: R (running)
Of course, detecting hung processes is an entirely separate issue.
/proc//stat is a more machine-readable format of the same info as /proc//status, and is, in fact, what the ps(1) command reads to produce its output.
Monitoring and/or killing a process is just a matter of system calls. I'd think the toughest part of your question would really be reliably determining that a process is "hung", rather than meerly very busy (or waiting for a temporary condition).
In the general case, I'd think this would be rather difficult. Even Windows asks for a decision from the user when it thinks a program might be "hung" (on my system it is often wrong about that, too).
However, if you have a specific program that likes to hang in a specific way, I'd think you ought to be able to reliably detect that.
Seeing as the question has changed:
http://procps.sourceforge.net/
Is the source of ps and other process tools. They do indeed use proc (indicating it is probably the conventional and best way to read process information). Their source is quite readable. The file
/procps-3.2.8/proc/readproc.c
You can also link your program to libproc, which sould be available in your repo (or already installed I would say) but you will need the "-dev" variation for the headers and what-not. Using this API you can read process information and status.
You can use the psState() function through libproc to check for things like
#define PS_RUN 1 /* process is running */
#define PS_STOP 2 /* process is stopped */
#define PS_LOST 3 /* process is lost to control (EAGAIN) */
#define PS_UNDEAD 4 /* process is terminated (zombie) */
#define PS_DEAD 5 /* process is terminated (core file) */
#define PS_IDLE 6 /* process has not been run */
In response to comment
IIRC, unless your program is on the CPU and you can prod it from within the kernel with signals ... you can't really tell how responsive it is. Even then, after the trap a signal handler is called which may run fine in the state.
Best bet is to schedule another process on another core that can poke the process in some way while it is running (or in a loop, or non-responsive). But I could be wrong here, and it would be tricky.
Good Luck
You may be able to use whatever mechanism strace() uses to determine what system calls the process is making. Then, you could determine what system calls you end up in for things like pthread_mutex deadlocks, or whatever... You could then use a heuristic approach and just decide that if a process is hung on a lock system call for more than 30 seconds, it's deadlocked.
You can run 'strace -p ' on a process pid to determine what (if any) system calls it is making. If a process is not making any system calls but is using CPU time then it is either hung, or is running in a tight calculation loop inside userspace. You'd really need to know the expected behaviour of the individual program to know for sure. If it is not making system calls but is not using CPU, it could also just be idle or deadlocked.
The only bulletproof way to do this, is to modify the program being monitored to either send a 'ping' every so often to a 'watchdog' process, or to respond to a ping request when requested, eg, a socket connection where you can ask it "Are you Alive?" and get back "Yes". The program can be coded in such a way that it is unlikely to do the ping if it has gone off into the weeds somewhere and is not executing properly. I'm pretty sure this is how Windows knows a process is hung, because every Windows program has some sort of event queue where it processes a known set of APIs from the operating system.
Not necessarily a programmatic way, but one way to tell if a program is 'hung' is to break into it with gdb and pull a backtrace and see if it is stuck somewhere.