Detecting deamons running

Detecting deamons running

[Luciano Moreira - igLnx]

I have a application that run like a deamon, which write in a file its PID,
that is used to stop it later by others programs. But, I ve noted that my
users send signal 9 to stop deamons, and my application cannot remove its
PID file, because it cannot handle singal 9, keeping its PID file at HD
(FileSystem).

Can someone sugest me a way to know the deamon's PID, without write it to a
file ?
OR
How can I do to know if my deamon is running and get its PID ?

Thanks,

Luciano

Re: Detecting deamons running

[Andrés Roldán]

$ pidof process

will return the PID or the PIDs of the specified process. If it returns
nothing, there is not such a process running.

Cheers

"Luciano Moreira - igLnx" <lucianolnx@ig.com.br> writes:

> I have a application that run like a deamon, which write in a file its PID,
> that is used to stop it later by others programs. But, I ve noted that my
> users send signal 9 to stop deamons, and my application cannot remove its
> PID file, because it cannot handle singal 9, keeping its PID file at HD
> (FileSystem).
>
> Can someone sugest me a way to know the deamon's PID, without write it to a
> file ?
> OR
> How can I do to know if my deamon is running and get its PID ?
>
> Thanks,
>
> Luciano
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Andres Roldan, CSO
Fluidsignal Group

Re: Detecting deamons running

[Glynn Clements]

Andrés Roldán wrote:

> > I have a application that run like a deamon, which write in a file its PID,
> > that is used to stop it later by others programs. But, I ve noted that my
> > users send signal 9 to stop deamons, and my application cannot remove its
> > PID file, because it cannot handle singal 9, keeping its PID file at HD
> > (FileSystem).
> >
> > Can someone sugest me a way to know the deamon's PID, without write it to a
> > file ?
> > OR
> > How can I do to know if my deamon is running and get its PID ?
> 
> $ pidof process
> 
> will return the PID or the PIDs of the specified process. If it returns
> nothing, there is not such a process running.

pidof will return all PIDs which match a given name, which isn't
necessarily the same thing as determining the PIDs of specific
processes.

E.g. if you want to find the PID of the sendmail daemon, you have to
read /var/run/sendmail.pid; "pidof sendmail" won't make any
distinction between the daemon and other processes with the name
"sendmail" (which may not even be running the same "sendmail"
program).

BTW, root should never use "killall", for similar reasons.

The correct solution is to use a PID file. If a user issues SIGKILL,
then tough; there are limits to how far you should go toward
preventing users from shooting themselves in the foot.

Note that the same problem exists for most other inter-process
communication mechansims, such as FIFOs, Unix domain sockets or SysV
IPC entities.

-- 
Glynn Clements <glynn.clements@virgin.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Detecting deamons running

[Luciano Moreira - igLnx]

EXPLAINING BETTER:

Today we'are writing the PID to a file, and when it is used (later), is
necessary to test de PID with "kill(pid, 0);", but still existing a problem:

When the deamon is droped down with SIGKILL, and the others programs or my
users stay a long time without consulting the deamon's PID, the OS could
raise a new process with the same PID (currently free), that is saved in the
deamon's PID file.

How can this problem be fixed ?  (how is it fixed today ?)

(Somebody suggest us to use shared memory (or SOCKET) mated with another
deamon, that whould be the "PID Server", instead using PID file - We think
that it's bad and so complex, and still can give us a "infinite problem" if
we need to control the new mated deamon)

Luciano Moreira

----- Original Message -----
From: "Glynn Clements" <glynn.clements@virgin.net>
To: <linux-c-programming@vger.kernel.org>
Sent: Friday, March 28, 2003 6:30 PM
Subject: Re: Detecting deamons running


>
> Andrés Roldán wrote:
>
> > > I have a application that run like a deamon, which write in a file its
PID,
> > > that is used to stop it later by others programs. But, I ve noted that
my
> > > users send signal 9 to stop deamons, and my application cannot remove
its
> > > PID file, because it cannot handle singal 9, keeping its PID file at
HD
> > > (FileSystem).
> > >
> > > Can someone sugest me a way to know the deamon's PID, without write it
to a
> > > file ?
> > > OR
> > > How can I do to know if my deamon is running and get its PID ?
> >
> > $ pidof process
> >
> > will return the PID or the PIDs of the specified process. If it returns
> > nothing, there is not such a process running.
>
> pidof will return all PIDs which match a given name, which isn't
> necessarily the same thing as determining the PIDs of specific
> processes.
>
> E.g. if you want to find the PID of the sendmail daemon, you have to
> read /var/run/sendmail.pid; "pidof sendmail" won't make any
> distinction between the daemon and other processes with the name
> "sendmail" (which may not even be running the same "sendmail"
> program).
>
> BTW, root should never use "killall", for similar reasons.
>
> The correct solution is to use a PID file. If a user issues SIGKILL,
> then tough; there are limits to how far you should go toward
> preventing users from shooting themselves in the foot.
>
> Note that the same problem exists for most other inter-process
> communication mechansims, such as FIFOs, Unix domain sockets or SysV
> IPC entities.
>
> --
> Glynn Clements <glynn.clements@virgin.net>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Detecting deamons running

[Glynn Clements]

Luciano Moreira - igLnx wrote:

> EXPLAINING BETTER:
> 
> Today we'are writing the PID to a file, and when it is used (later), is
> necessary to test de PID with "kill(pid, 0);", but still existing a problem:
> 
> When the deamon is droped down with SIGKILL, and the others programs or my
> users stay a long time without consulting the deamon's PID, the OS could
> raise a new process with the same PID (currently free), that is saved in the
> deamon's PID file.
> 
> How can this problem be fixed ?  (how is it fixed today ?)

It can't be fixed, and all existing daemons have the same problem. 

OTOH, most daemons run under system accounts, so normal users can't
send signals to them, and anyone with root privilege presumably has
enough sense not to use SIGKILL.

> (Somebody suggest us to use shared memory (or SOCKET) mated with another
> deamon, that whould be the "PID Server", instead using PID file - We think
> that it's bad and so complex, and still can give us a "infinite problem" if
> we need to control the new mated deamon)

What exactly is the .pid file meant to achieve? Is it just a
convenience, or are there system integrity considerations?

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: Detecting deamons running

[Luciano Moreira - igLnx]

Our users are issuing SIGKILL to deamons and turning power off without
shutdown, and their "boss" are requesting us to add more integrity to the
system.

Thinking about your questions and considering that kill(pid, 0), will
returns ok, for any runnig process, including process belonging by others
users  (I cant code 'n test it now - I dont know). I think that will be
necessary to send a "User Signal" to test a valid PID, like as a "private"
message, thus, if the proccess was my deamon, kill() will returns
successful, otherwise, the PID can be another PID beyond my "User Table
Process".

Well, above was only a proposal to add more integrity to the system, but I
know that it doesnt is perfect, without sureness that never will exists
another deamon that handles the "User Signal" running under this user.

I HAVE TO SAY: Our application is multiplataform, it needs to run over AIX,
Linux, SCOUnix, Solaris (and Windows with a lot of #ifdefs) - Currently it's
running well over all these plataforms.

Thank you very much,

Luciano



----- Original Message -----
From: "Glynn Clements" <glynn.clements@virgin.net>
To: "Luciano Moreira - igLnx" <lucianolnx@ig.com.br>
Cc: <linux-c-programming@vger.kernel.org>
Sent: Friday, March 28, 2003 9:45 PM
Subject: Re: Detecting deamons running


>
> Luciano Moreira - igLnx wrote:
>
> > EXPLAINING BETTER:
> >
> > Today we'are writing the PID to a file, and when it is used (later), is
> > necessary to test de PID with "kill(pid, 0);", but still existing a
problem:
> >
> > When the deamon is droped down with SIGKILL, and the others programs or
my
> > users stay a long time without consulting the deamon's PID, the OS could
> > raise a new process with the same PID (currently free), that is saved in
the
> > deamon's PID file.
> >
> > How can this problem be fixed ?  (how is it fixed today ?)
>
> It can't be fixed, and all existing daemons have the same problem.
>
> OTOH, most daemons run under system accounts, so normal users can't
> send signals to them, and anyone with root privilege presumably has
> enough sense not to use SIGKILL.
>
> > (Somebody suggest us to use shared memory (or SOCKET) mated with another
> > deamon, that whould be the "PID Server", instead using PID file - We
think
> > that it's bad and so complex, and still can give us a "infinite problem"
if
> > we need to control the new mated deamon)
>
> What exactly is the .pid file meant to achieve? Is it just a
> convenience, or are there system integrity considerations?
>
> --
> Glynn Clements <glynn.clements@virgin.net>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>