How to check (in C) if a process (with known pid) is still alive?
Yong Yuan
Hi,
If I don't call exec() or system(), can I find out if a process
is still alive? (I know its pid)
Thanks!
--
Yong (yo...@rockmag.gso.uri.edu)
Can Ekingen
You can use kill system call with signal number 0 (zero )
kill(pid,0)
for more info man 2 kill
C.EKINGEN
-
-
-
Amrit Jassal
Yong Yuan wrote:
>
> Hi,
>
> If I don't call exec() or system(), can I find out if a process
> is still alive? (I know its pid)
>
> Thanks!
>
> --
> Yong (yo...@rockmag.gso.uri.edu)
======
NAME
kill - send a signal to a process or a group of processes
SYNOPSIS
#include <signal.h>
int kill (pid, sig)
pid_t pid; int sig;
DESCRIPTION
kill sends a signal to a process or a group of processes.
The process or group of processes to which the signal is to
be sent is specified by pid. The signal that is to be sent
is specified by sig and is either one from the list given in
signal(2), or 0. If sig is 0 (the null signal), error
checking is performed but no signal is actually sent. This
can be used to check the validity of pid.
.....
--
Amrit Jassal
KPMG Peat Marwick,
Enterprise Package Solutions,
Palo Alto.
AJ Musgrove
: If I don't call exec() or system(), can I find out if a process
: is still alive? (I know its pid)
: Thanks!
if (sigsend(P_PID,pid,0)<0)
if (errno==ESRCH)
/* proc doesn't exist */
else
/* some oether error */
else
/* proc exists */
You can substitute sigsend(P_PID,pid,0) with kill(pid,0) if you want.
--
AJ Musgrove
----------------------------------------------------------------
My opinions do not necessarily reflect those of my employer, or
anyone else for that matter. O-
----------------------------------------------------------------
vijay kukreja
/proc/<PID> should exists if the process PID is still running.
Use stat() system call to check for file existence.
man stat
man proc
Yong Yuan <yo...@rockmag.gso.uri.edu> wrote in article
<59nn8m$1...@bubbla.uri.edu>...
> Hi,
>
> If I don't call exec() or system(), can I find out if a process
> is still alive? (I know its pid)
>
> Thanks!
>
> --
> Yong (yo...@rockmag.gso.uri.edu)
>
AJ Musgrove
vijay kukreja <vi...@litle.net> wrote:
: /proc/<PID> should exists if the process PID is still running.
: >
Not to split hairs, but I believe that access() would be clearer in this
case, as F_OK in amod is "Check existance of file". stat() could be
confusing down the road for a maintence programmer or something.
Just my 0.02$ :)
Stefan Persson
In article <5a1is1$2...@news1.iamerica.net>,
AJ Musgrove <musg...@xavier.varmm.com> wrote:
>vijay kukreja <vi...@litle.net> wrote:
>
>: Yong Yuan <yo...@rockmag.gso.uri.edu> wrote in article
>: <59nn8m$1...@bubbla.uri.edu>...
>: > Hi,
>: >
>: > If I don't call exec() or system(), can I find out if a process
>: > is still alive? (I know its pid)
>: >
>: > Thanks!
The easiest way should be to do a 'kill(pid, 0);', if the process exists,
kill returns zero, otherwise -1.
/stefan
--
'The number of Unix installations has grown to ten, with more expected.'
<Unix Programmer's Manual, 2nd ed.; june 1972>
GMacdon680
>i n article <5a1is1$2...@news1.iamerica.net>,
>AJ Musgrove <musg...@xavier.varmm.com> wrote:
>>vijay kukreja <vi...@litle.net> wrote:
>>
>>: Yong Yuan <yo...@rockmag.gso.uri.edu> wrote in article
>>: <59nn8m$1...@bubbla.uri.edu>...
>>: > Hi,
>>: >
>>: > If I don't call exec() or system(), can I find out if a process
>>: > is still alive? (I know its pid)
>>: >
>>: > Thanks!
>The easiest way should be to do a 'kill(pid, 0);', if the process exists,
>kill returns zero, otherwise -1.
On newer systems(SV4+) you can also check for the existance of
/proc/pid, it's either a file or a directory. However remember that the
process may be dying and may not exist by the time you get the
response. Kill(pid,0) however is good for most uses.
Stefan Persson
In article <5a1is1$2...@news1.iamerica.net>,
AJ Musgrove <musg...@xavier.varmm.com> wrote:
>vijay kukreja <vi...@litle.net> wrote:
>
>: Yong Yuan <yo...@rockmag.gso.uri.edu> wrote in article
>: <59nn8m$1...@bubbla.uri.edu>...
>: > Hi,
>: >
>: > If I don't call exec() or system(), can I find out if a process
>: > is still alive? (I know its pid)
>: >
>: > Thanks!
The easiest way should be to do a 'kill(pid, 0);', if the process exists,
kill returns zero, otherwise -1.
/stefan
GMacdon680
>i n article <5a1is1$2...@news1.iamerica.net>,
>AJ Musgrove <musg...@xavier.varmm.com> wrote:
>>vijay kukreja <vi...@litle.net> wrote:
>>
>>: Yong Yuan <yo...@rockmag.gso.uri.edu> wrote in article
>>: <59nn8m$1...@bubbla.uri.edu>...
>>: > Hi,
>>: >
>>: > If I don't call exec() or system(), can I find out if a process
>>: > is still alive? (I know its pid)
>>: >
>>: > Thanks!
>The easiest way should be to do a 'kill(pid, 0);', if the process exists,
>kill returns zero, otherwise -1.
On newer systems(SV4+) you can also check for the existance of
Casper H.S. Dik - Network Security Engineer
d4st...@dtek.chalmers.se (Stefan Persson) writes:
>The easiest way should be to do a 'kill(pid, 0);', if the process exists,
>kill returns zero, otherwise -1.
kill() can also return -1 if you don't have permission to kill it.
You should test:
kill(pid, 0) == -1 && errno == ESRCH
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Andrew Gierth
>>>>> "Stefan" == Stefan Persson <d4st...@dtek.chalmers.se> writes:
Stefan> The easiest way should be to do a 'kill(pid, 0);', if the
Stefan> process exists, kill returns zero, otherwise -1.
Actually kill can quite legitimately return -1 even if the process exists.
To use this method generally, you also need to examine errno.
--
Andrew Gierth (and...@microlise.co.uk)
"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam
Boyd Roberts
In article <01bbf394$89d704a0$9316...@chromium.litle.net>, vi...@litle.net says...
>/proc/<PID> should exists if the process PID is still running.
All very fine if you're on System V release 4. A somewhat more portable
way is to use kill(2) with signal 0.
--
Boyd Roberts <bo...@france3.fr> N 31 447109 5411310
``Not only is UNIX dead, but it's starting to smell really bad.'' -- rob
James Youngman
In article <59nn8m$1...@bubbla.uri.edu>, yo...@rockmag.gso.uri.edu says...
>
>Hi,
>
>If I don't call exec() or system(), can I find out if a process
>is still alive? (I know its pid)
Send it signal 0 using kill(2).
--
James Youngman VG Gas Analysis Systems |The trouble with the rat-race
Before sending advertising material, read |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.
Joerg Pommnitz
In <5aitb7$j...@halon.vggas.com>, JYou...@vggas.com (James Youngman) writes:
>
>Send it signal 0 using kill(2).
>
still alive. Since a pid can be reused, it might run a completely different
program.
gl...@ov.com
Unless you have a really high turnover of processes, it is unlikely that
the same process ID will be reused within the same day. Each new process
is assigned a higher process ID than the last, and the count does not
wrap until 32768. This means that you have to start and stop at least
32000 processes before an ID will be reused.
Andrew Gierth
>>>>> "Fletcher" == Fletcher Glenn@ov com <gl...@ov.com> writes:
>> This only helps to determine whether a process with the specified pid is
>> still alive. Since a pid can be reused, it might run a completely different
>> program.
Fletcher> Unless you have a really high turnover of processes, it is
Fletcher> unlikely that the same process ID will be reused within the
Fletcher> same day. Each new process is assigned a higher process ID
Fletcher> than the last, and the count does not wrap until 32768.
Fletcher> This means that you have to start and stop at least 32000
Fletcher> processes before an ID will be reused.
Those limits are system-dependent.
In any case, the rate of process turnover can be very variable. Consider,
for example, the effect of running a shell script that does a mass rename
or edit in a directory with thousands of files in it. If you work at it,
you can wrap PIDs in only a few minutes even on a fairly modest machine.
Also watch out for AIX - it has an unusual scheme for allocating pids that
can (in rare cases) cause them to be reused very quickly.
Mark A. Crampton
Andrew Gierth wrote:
>
> >>>>> "Fletcher" == Fletcher Glenn@ov com <gl...@ov.com> writes:
>
> >> This only helps to determine whether a process with the specified pid is
> >> still alive. Since a pid can be reused, it might run a completely different
> >> program.
>
I used popen and call ps -fp (not ucb as -f is illegal), and parsed the output since I had to
do it as a non-root program. You can get more efficient using system calls such as priocntl()
(SVR4) but they require root priviledge.
Nicolas Vazquez
Lew Pitcher
> Yall still here
You /do/ realize that you replied to a thread last posted to over 24 years ago, right?
--
Lew Pitcher
"In Skills, We Trust"
James K. Lowden
Lew Pitcher <lew.p...@digitalfreehold.ca> wrote:
> > Yall still here
>
>
> You /do/ realize that you replied to a thread last posted to over 24
> years ago, right?
email threads before time_t rolls over.
--jkl
Boris Dorestand
> On Fri, 30 Apr 2021 16:29:59 -0700, Nicolas Vazquez wrote:
>
>> Yall still here
>
> You /do/ realize that you replied to a thread last posted to over 24
> years ago, right?
header? How do you do that so easily? I'd love to the same. Thanks!
Lew Pitcher
https://groups.google.com/g/comp.unix.programmer/c/xN3-YrzTeLk/m/e-wNQjBOzsEJ
James Kuyper
Enjoy this while you can. When Deja News was maintaining the archives,
they have a very powerful and reasonably fast search engine. When Google
took over the archive, virtually every change they've made has had the
effect of making the archives less useful by reason of being harder to
search. I suspect the end is nigh - pretty soon Google is going to admit
that they have no interest in continuing to maintain and provide access
to those archives. I wouldn't be surprised if they simply delete them
when the time comes, rather than letting someone else take over
responsibility.
Boris Dorestand
> On Tue, 04 May 2021 17:54:46 -0300, Boris Dorestand wrote:
>
>> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>>
>>> On Fri, 30 Apr 2021 16:29:59 -0700, Nicolas Vazquez wrote:
>>>
>>>> Yall still here
>>>
>>> You /do/ realize that you replied to a thread last posted to over 24
>>> years ago, right?
>>
>> How did you know? Did you look the original message in the references
>> header? How do you do that so easily? I'd love to the same. Thanks!
>
> I looked it up in google's C.U.P mirror
>
> https://groups.google.com/g/comp.unix.programmer/c/xN3-YrzTeLk/m/e-wNQjBOzsEJ
wish such mirror would index it by message-id --- or perhaps (group,
message-id). It doesn't seem to be like that.
The message included
In-Reply-To: <32DA98...@softart.com>#1/1>
The references were
<5amorl$d...@rtpnews.raleigh.ibm.com>
<32DA98...@softart.com>#1/1>
My desire is to look it up from my news reader.
Boris Dorestand
https://archive.org/details/usenet
--- should have a complete archive of the USENET. Shouldn't it? But
it's not clear exactly what they have there. They seem to have various
small archives.
But if they have a superset (considering the union of everything they
have), someone could just join them all. With so many computers in the
world, why can't we lookup a USENET message by message-id on the web?
No profit from this?
The web system should provide the raw message and an API so that NNTP
clients can make use of it. (Users of the API would register and
respect usage limits, of course.)
Lew Pitcher
Best case, you can use the
Message-ID:
of the message you are looking for, or the
In-Reply-To:
or
References:
that lead to it.
If your news provider keeps an archive, then your news reader /might/
be able search that archive. But, FWIW, most news providers don't keep
archives of past articles, preferring to drop articles from their store
after a reasonable (and often short) period of time.
HTH
James Kuyper
> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>
>> On Tue, 04 May 2021 17:54:46 -0300, Boris Dorestand wrote:
>>
>>> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>>>
>>>> On Fri, 30 Apr 2021 16:29:59 -0700, Nicolas Vazquez wrote:
>>>>
>>>>> Yall still here
>>>>
>>>> You /do/ realize that you replied to a thread last posted to over 24
>>>> years ago, right?
>>>
>>> How did you know? Did you look the original message in the references
How to check (in C) if a process (with". The "Re:" indicates that it was
a response to some earlier message, so I knew there should be earlier
messages. I could have also figured it out by looking at the message
headers, but just noticing the "Re:" is much simpler.
>>> header? How do you do that so easily? I'd love to the same. Thanks!
>>
>> I looked it up in google's C.U.P mirror
>>
>> https://groups.google.com/g/comp.unix.programmer/c/xN3-YrzTeLk/m/e-wNQjBOzsEJ
>
> But how did you know that this was the URL? Did you have to search? I
https://groups.google.com/g/comp.unix.programmer
I then searched manually through the threads to find the title of this
thread. Since the most recent message on that thread was posted quite
recently, it was near the top. However, if you're interested in an older
message, there's a box near the top of the screen which says "Search
conversations within comp.unix.prog...". You can just type a simple
search string in that box, or you can fill out a slightly more
sophisticated search form by clicking the downward-pointing triangle on
the right hand side of that search box.
If you want to search all groups, click on the downward-pointing
triangle to the left of the search box.
They used to have an option of searching for a particular message using
its usenet message ID, but that's one of the many useful features that
they have slowly been removing over the years. Even as recently as a
year ago, Google Groups' search capabilities were significantly more
sophisticated than they are today (while being positively primitive
compared to what you could do with Deja News).
Boris Dorestand
my NNTP server. For instance, why doesn't Google Groups lets us do that
right now since it probably has it all archived and available on the
web?
Boris Dorestand
curl http://somewhere.example.com/comp.unix.programmer/message-id-xyz
or even better
curl http://somewhere.example.com/message-id-xyz.
It's a pity no archive lets us do that.
> They used to have an option of searching for a particular message using
> its usenet message ID, but that's one of the many useful features that
> they have slowly been removing over the years. Even as recently as a
> year ago, Google Groups' search capabilities were significantly more
> sophisticated than they are today (while being positively primitive
> compared to what you could do with Deja News).
I think it's pretty simple. Index it properly and let it be fetched
through an HTTP API protected by keys that limit usage. Then let people
build their software on it. If it gets expensive, handle it to some
organization such as archive.org or create a non-profit for it. A lot
of people would devote themselves to keep this up.
James Kuyper
...
> my NNTP server. For instance, why doesn't Google Groups lets us do that
> right now since it probably has it all archived and available on the
> web?
dropped it. Why? I have no idea - nothing seems particularly sane about
the way Google Groups has been managed. The simplest explanation is that
Google has no particular interest in providing useful access to their
usenet archives, but if that's the case, why do they bother providing
any access to them at all? Why do they regularly modify their interface
to make it less useful? Surely just maintaining their existing software
would have been easier?
Boris Dorestand
packages of all the archive and let us handle it some other way. I
wonder what is the size it of all.
James Kuyper
> James Kuyper <james...@alumni.caltech.edu> writes:
...
> > Google has no particular interest in providing useful access to their
> > usenet archives, but if that's the case, why do they bother providing
> > any access to them at all? Why do they regularly modify their interface
> > to make it less useful? Surely just maintaining their existing software
> > would have been easier?
> All good questions. They should just provide us with a series of
> packages of all the archive and let us handle it some other way. I
> wonder what is the size it of all.