Printable View
Is there anyway to find out the pid of a process totally unrelated to the one you're in?
The only thing I found was sysctl here but I don't think I should be using functions that go that close to the kernel.
I know the name of the executable of course. And all the windows solutions don't apply because I have have to do it in c and I'm on windows.
Thanks for any ideas
I'm confused. Why do you think a linux command has any hope of working on a windows box?
(And, by definition, once you say the word "pid" then you are "that close to the kernel".)
My bad - I meant to say I'm on linux, sorry.Quote:
I'm confused. Why do you think a linux command has any hope of working on a windows box?
Maybe I didn't write correctly, what I meant to say was that with sysctl you can change kernel parameters at run time. I'm pretty ok with reading that kind of information but not with being able to modify it.Quote:
(And, by definition, once you say the word "pid" then you are "that close to the kernel".)
Anyway, do you know how to find the pid?
Moved to Linux Programming.
Have a look through all the pseudo-files in /proc would be my guess.
What happens if there's more than one match?
I was going to suggest ps + grep, but that's not necessarily a C solution.
I don't know what you mean by this :(Quote:
Have a look through all the pseudo-files in /proc would be my guess.
I thought about launching a fork to this and then somehow manipulate the output into my process but I have a feeling that I'm over complicatingQuote:
I was going to suggest ps + grep, but that's not necessarily a C solution.
start with ls /proc
There should be an entry for each active PID
In each /proc/PID are some other files which describe the process.
One of those should tell you what you need to know.
Yes, this is how 'ps' works, I don't think there is another way.Quote:
start with ls /proc
There should be an entry for each active PID
This is why '/proc'[esses] is named like that after all.
Cant you call ps within a C code (with exec family) and redirect the stdout output to a file? Or read from the stdout to see what ps printed?
Yes the solution I'm thinking bout is launching a process to do an exec with ps aux --sort user but before launching it switching it's stdout file descriptor to a pipe to the father process.
My problem with this is that I'll have to do that over and over until the process dies.
Isn't that busy waiting and if so bad programming?
Relevant thread elsewhere, perhaps.
Well. Obviously you wouldn't do it continuously; once a minute, once every five minutes, however often you want an update. But if you want something real-time-ish, then it's going to have to run all the time, I would guess (no matter what solution you choose, since signals are Right Out).Quote:
Originally Posted by kotoko
What else can you do though? You can use search the /proc directory directly instead of using ps or ls /proc and having to parse the printed information. That would be better.Quote:
Originally Posted by kotoko
What do you want to do anyways? The question was about finding the pid of the process. That won't change...
Maybe I should reformulate the question.Quote:
The question was about finding the pid of the process. That won't change...
I need to do a watchdog for a process. That process (let's call it p2) is also coded by me.
However, since this is a assignment for school, I'm supposed to figure a way to see if p2 is still alive without p2 doing anything at all.
The way I'm thinking this means no semaphores and no pipes.
I thought that if I had the pid things would be easier to find if the process was running hence my question.
As suggested in the other thread, the EASY solution is to let p2 write it's own pid to a file (because it's easy to find out which pid your own process has).
However, another solution is to introduce another application (call it p3) that acts as a proxy-object for p2 - essentially, it just starts p3, writes the process id to a file (since it is starting the process, it also knows it's pid from the call to fork). Once it's done with that, it can fall asleep (perhaps waiting for p2 to signal it's own death?).
If both of these solutions are no good, then you do indeed some way or another scan the process list - whether you read the output of ps or reading from /proc. By the way, popen("ps") may be a simple way to get your process output into a pipe.
Going back to the context of "watchdog" - whilst application dying by exiting is certainly one case of "no longer working", there are many other instances of applications not working where the process is still alive - it's just not doing what you expect it to do (e.g. it's got stuck in an infinite loop [while-loop with scanf() and poor checking of scanf's return value, or poor handling of error-situations even if the error is indeed detected, is a typical case of this], or it's waiting inside the OS for something to happen, and it never happens [e.g. reading from a pipe, but the other side is not writing anything, but also not closing the pipe, or waiting for a semaphore that never gets signalled]).
The above can of course not be detected by checking if the process is still alive - it will be alive but not working.
--
Mats
The easiest way would be to have the watchdog launch p2. Then you not only have the PID, you actually get a signal when the process dies, and you can get its exit code.
I actually would like to do something similar. Perhaps there might be a POSIX API that allows you to do so?
Not directly, but if you use the method described by CornedBee, the signal SIGCHLD will tell you that a child process exited.Quote:
Originally Posted by beyonddc
Again, read the discussion about "what does alive mean" that I instigated above.
--
Mats
Unfortunately my application doesn't exec the process that needs to be monitor.Quote:
Originally Posted by matsp
Again, as mats said, what does it mean for this process to be alive?
For example, does it log something to a log file periodically? If so, watch the log and check that the update time doesn't exceed a certain threshold. Does it create a system-wide mutex or semaphore for which existence could be queried? Does it bind to a port as a listener such that you could check to see if you can bind to that port? There are a number of ways to do this sort of thing.
Those are all good thoughts. I'll look into it a bit more.Quote:
Originally Posted by rags_to_riches
We're looking into using SNMP to query the system for all running software information.