Unusual inetd behavior with regards to bootp.

[Steven E. Protter]

11.11
11.23
11.31
Superdome Itanium
PA-RISC rp8420

Patching: Perhaps 18 months behind, though patched by a custom QPK/Gold patch bundle created for us by HP

Patch Policy: Annual, though 2009 there was no major patch set rollout.

We have noticed the following on a number of serveres.

1) bootp does not terminate when we bounce inetd.

ex: Ignite server, has a bootp process, and a inetd process. bootp is configured in inetd.

inetd -k or kill

bootp process continues to run.
netstat -an shows a listener, but no open inbound bootp requests.

Standard inetd.conf


tftp dgram udp wait root /usr/lbin/tftpd tftpd\
/opt/ignite\
/var/opt/ignite
bootps dgram udp wait root /usr/lbin/bootpd bootpd

instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd

My understanding was that inetd in this configuration starts a bootp process when there is a request for boot.

Just confirmed this on a system that is behaving more normally.

The team here performed the following test on a system with a bootp process running:

inetd -k
# Wait a few minutes.
ps -ef | grep boot
# process is there
netstat -an | grep "67 "
# Listener is there.
indetd

# Same tests, same results.

Checked the patch database, found nothing on any of the three aforementioned OS versions.

Questions:
1) If there are no active bootp requests to the Ignite server, should bootp processes terminate when you terminate inetd?
2) Can you check one of your systems out and see if they work the same way.
3) If you have seen this, do you think its a bootp problem (failure to terminate) or a inetd problem (failure to send terminate signal)?
4) If my understanding is wrong, e.g. inetd does not shut down child bootp processes for some reason, please explain/post links as to why.

SEP
Contractor for:
Dana Corporation
Toledo, Ohio

[Patrick Wallek]

>>1) If there are no active bootp requests to the Ignite server, should bootp processes terminate when you terminate inetd?

I would not expect this to happen.

You need to stop and think about what exactly inetd does. When a request comes in for a service that inetd handles, then that service is started. However, inetd has nothing to do with the termination of that service. That is left solely to the service itself.

Think about telnet and FTP. Those are handled by inetd as well. If you telnet to a server and subsequently stop inetd, do you expect your telnet connection to drop? I don't.

If your inetd daemon happens to die for some reason, do you really want all services started by it to die as well? I think not!

I just did a test on one of my development servers.

I telnet'ed to it.
In another window I stopped inetd on that server.
My telnet connection still worked.
I then restarted inetd.

If stopping inetd actually did terminate any services that it had started (telnet, ftp, bootp, etc.) THEN I would worry.

[Duncan Edmonstone]

SEP,

Agree with Patrick's comments and would just add this snippet from the bootpd man page:

bootpd starts when a boot request arrives. If it has not received
another boot request after 500 minutes, bootpd exits. The -t option
can be used to specify a different timeout value in minutes (such as
-t20). With a timeout value of zero (-t0), bootpd never exits.


So it stays up for about 8 hours unless you change the inetd.conf entry...

HTH

Duncan

[Steven E. Protter]

Another fact to consider.

The bootp process on some systems was running three weeks with no requests.

So it looks like a bootp problem, not an inetd problem.

A look through the patch database shows me no specific patches for any OS.

How big a deal do you think it is bootp not stopping after 500 seconds of inactivity.

The inetd behavior makes sense. Seems bootp is kind of broken.

SEP

[Steven E. Protter]

Prior post. Change minutes to seconds.

[Patrick Wallek]

>>How big a deal do you think it is bootp not
>>stopping after 500 seconds of inactivity.

Well, I doubt that bootp would use much CPU or RAM while waiting for a boot request, so from that perspective it's probably not a big deal.

However, from the perspective of it not exiting normally, it sounds like there may be a problem.

A test might be in order.

You might try changing

bootps dgram udp wait root /usr/lbin/bootpd bootpd

to

bootps dgram udp wait root /usr/lbin/bootpd bootpd -t3

Then run 'inetd -c' and see what happens then.

If bootp is not running and you make a bootp request, then it should stop 3 minutes later. If it does not, then it may be worth a call to HP to see if there is a known problem and whether or not a patch exists.

[Patrick Wallek]

I would patch bootp to the latest level on a test server and see if it helps.

I found the following for the latest bootp patches:

PHNE_39700: s700_800 11.11 bootpd(1M)/DHCP, tftp(1) and tftpd(1M) patch
http://www11.itrc.hp.com/service/patch/patchDetail.do?patchid=PHNE_39700&sel={hpux:11.11,}&BC=main|search|

PHNE_39668:s700_800 11.23 bootpd(1M)/DHCP, tftp(1) and tftpd(1M) patch
http://www11.itrc.hp.com/service/patch/patchDetail.do?patchid=PHNE_39668&sel={hpux:11.23,}&BC=main|search|

PHNE_39443:11.31 bootpd(1M)/DHCP, tftp(1) and tftpd(1M) patch
http://www11.itrc.hp.com/service/patch/patchDetail.do?patchid=PHNE_39443&sel={hpux:11.31,}&BC=main|search|

All of the above patches were release in Sep. 2009.

[Steven E. Protter]

Hmm.

Patches.

I do have a test system I can try them out on.

Will do the test.

Very nice. I know the patches do not deal with this issue specifically, however it may just be rolled into the patch.

SEP

[Steven E. Protter]

They never let me patch.

Bummer.