Re: Killing a daemon process
Re: Killing a daemon process
- Subject: Re: Killing a daemon process
- From: Frode <email@hidden>
- Date: Mon, 24 Oct 2005 13:39:43 +0200
Hi!
I'm not an expert on the subject but the format of the two
configuration files differs -- inetd.config has space-separated-value
format and xinetd.config has the key-value format. So either your
program requires the latter or needs to be compatible with the former.
Note that at least for the super-server (x)inetd, you don't actually
kill the process but send a "reconfiguration signal" (hang-up signal,
kill -HUP) after you have modified the configurations. This cause
(x)inetd to reconfigure itself by re-reading the configuration file
(/etc/xinetd.conf) and the include directory (/etc/xinetd.d). However,
I don't know if this "interapplication communication" is something
general or particular to the super-server.
>man inetd
Inetd rereads its configuration file when it receives a hangup
signal,
SIGHUP. Services may be added, deleted or modified when the
configura-
tion file is reread. Inetd creates a file /var/run/inetd.pid that
con-
tains its process identifier.
>man xinetd
xinetd performs certain actions when it receives certain
signals. The
actions associated with the specific signals can be redefined
by edit-
ing config.h and recompiling.
SIGHUP causes a hard reconfiguration, which means that
xinetd
re-reads the configuration file and
terminates the
servers for services that are no longer
available.
Access control is performed again on running
servers by
checking the remote location, access times and
server
instances. If the number of server instances is
lowered,
some arbitrarily picked servers will be killed
to sat-
isfy the limit; this will happen after any
servers are
terminated because of failing the remote
location or
access time checks. Also, if the INTERCEPT
flag was
clear and is set, any running servers for that
service
will be terminated; the purpose of this is to
ensure
that after a hard reconfiguration there will be
no run-
ning servers that can accept packets from
addresses that
do not meet the access control criteria.
Regards,
/Roger
2005-10-24 kl. 04.39 skrev email@hidden:
I am, but I have decided to use information from Apple's example
PIDFromBSDProcessName to solve this problem. I was not aware of
inetd.pid, thanks for the extra info.
Thanks,
Kris
Hi!
2005-10-20 kl. 22.54 skrev email@hidden:
The problem is on older OS X versions (10.3.4) this .pid file does
not exist. Is there an easier way to kill a root process, or get the
PID for it?
Are you refering to xinetd.pid, which succeeded inetd.pid?
/Roger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden