What's Chris been doing?

(I’ve also posted this entry as a comment to LCFG bug 146.)

I’ve just tried

[orkney]root: lsof -i | grep 732

and this is what I see:

rpc.statd 3094 rpcuser    7u  IPv4   7031       TCP *:732 (LISTEN)

This was after a couple of reboots. Before the reboot nothing was using port
732 (client hadn’t started – because before *that* I’d mREMOVEd lcfg_client
from boot.services and rebooted until I got the machine coming up without
client starting on boot.)

Here’s what ‘man rpc.statd’ has to say about ports:

-o, –outgoing-port port
specify a port for rpc.statd to send outgoing status requests
from. By default, rpc.statd will ask portmap(8) to assign it a
port number. As of this writing, there is not a standard port
number that portmap always or usually assigns. Specifying a
port may be useful when implementing a firewall.

-p, –port port
specify a port for rpc.statd to listen on. By default,
rpc.statd will ask portmap(8) to assign it a port number. As of
this writing, there is not a standard port number that portmap
always or usually assigns. Specifying a port may be useful when
implementing a firewall.

No LCFG components mention rpcstatd. Two /etc/init.d scripts do, rstatd and
nfslock.
rstatd isn’t in boot.services but nfslock is. nfslock also starts up earlier
than client does/did.
Looking at nfslock, it starts statd and *optionally* specifies ports according
to variables defined in /etc/sysconfig/nfs:

[orkney]root: grep -i stat /etc/sysconfig/nfs
# Optional arguments passed to rpc.statd. See rpc.statd(8)
#STATDARG=""
# Port rpc.statd should listen on.
#STATD_PORT=662
# Outgoing port statd should used. The default is port
#STATD_OUTGOING_PORT=2020
#STATD_HA_CALLOUT="/usr/local/bin/foo"

Since those are commented out just now it doesn’t ask for particular ports.

Looking at /etc/services, both of those ports suggested in the commented-out
entries in /etc/sysconfig/nfs are already being used for other things

The test 755 slept happily last night, three times, and was fine when it woke up this morning.

However on reboot it again got stuck starting the client component. I’ve entered this as bug 146 in the LCFG bug tracker.

I’ve written some guidelines on how to go about debugging sleep-related problems.

The test 755′s most recent difficulty turned out to be not a crash or a total machine hang, but something that happened the last time I rebooted it. I can’t now remember why it was necessary to reboot the machine, but anyway, I had started the reboot then departed for pleasanter climes. When I got back to it today the machine was half-booted and showing “LCFG mailng [OK]” at the bottom of a list of startup messages. Which means that it had completed mailng and was starting the next thing on the list: the client component. I later retrieved the client log and at the hang it was saying:

01/06/09 16:42:53: >> context
01/06/09 16:43:16: >> start
01/06/09 16:43:16: configuration changed
01/06/09 16:43:16: starting daemon [4283/732] version 2.2.37 04/17/09 13:53:56
01/06/09 16:43:16: warnings: conflict,context,dirs,error,localprofile,notify,parse,rpms,server
01/06/09 16:43:16: ** can’t bind UDP socket
01/06/09 16:43:16: ** Address already in use

When I restarted the machine today the client component started OK and the machine booted successfully. This time the client log said:

03/06/09 12:31:57: >> context
03/06/09 12:32:19: >> start
03/06/09 12:32:19: configuration changed
03/06/09 12:32:19: starting daemon [4291/732] version 2.2.37 04/17/09 13:53:56
03/06/09 12:32:19: warnings: conflict,context,dirs,error,localprofile,notify,parse,rpms,server
03/06/09 12:32:19: context check requested
03/06/09 12:32:19: new context: booting=true
03/06/09 12:32:23: profile accepted: 2921cae88f21209cf706dec15bafd4b5
03/06/09 12:33:27: >> context
03/06/09 12:33:27: context check requested
03/06/09 12:33:27: new context: default
03/06/09 12:33:30: profile accepted: 2921cae88f21209cf706dec15bafd4b5

This morning’s development meeting went well, a big improvement on previous ones I think: it helps far more to talk briefly about the real progress on each project than to go on about deadlines.