inet down/service guard

[Quark]

Hi,

I have a question about the inetd daemon.
On one of my systems the 'inetd' daemon was not running anymore.
When I looked in the syslog, I saw the following message:
"
inetd[908]: Going down on signal 15
"

I am correct to asume that with a signal 15 the inetd daemon was killed manually (by someone of some script)?

Furthermore, after the inetd daemon stopped, service guard behaved strangly. Apparently service guard uses the inetd daemon (probably via rsh) to query the nodes of the cluster.
When I for example executed the 'cmviewcl' command on another cluster node, it stated that the packages on the node where the inetd daemon was down, were not running.
After the restart of the inetd, the cmviewcl command returned the correct status of the packages.
It seems odd that service guard relies on the inetd. In my humble opinion, the inetd is not a critical system daemon.
When I look at the /etc/inetd.conf file I see the following entries:
"
hacl-cfg dgram udp wait root /usr/lbin/cmclconfd cmclconfd -p
hacl-cfg stream tcp nowait root /usr/lbin/cmclconfd cmclconfd -c
"

I am assuming there are used for service guard.

Is there a way to configure service guard not to use inetd?

With kind regards,

Kd

[Duncan Edmonstone]

Kris,

Serviceguard uses inetd for the purposes of reporting and configuration (witness the cmviewcl command). It does NOT need inetd for the cluster to remain stable and functioning - all heartbeat traffic goes nowhere need inetd.

And no, there is no way to configure it to not use inetd.

HTH

Duncan

[melvyn burnard]

inetd is used by SG for opening a socket connection when you do something like a cmviewcl, and inetd then fires of the required service, in this case cmclconfd.
If inetd is not running, SG is not the only service that will fail.

[Kent Ostby]

Kris --

Usually when I see inetd going down on signal 15 in conjunction with a ServiceGuard problem, it generally means that someone did a reboot of the system (which spawns kill all and send kill -15 to people), BUT someone could have just sent inetd a kill signal.

Check inetd.conf and see if there was a change made around that time.

A lot of times, people will update the inetd.conf and then kill and restart inetd to have the new changes take effect.