Rcpd doens't start because of UUID problem

[Carlos André]

Hi all,
I am running HP-UX 11.0, and am currently hardening a server for security reasons. I've stopped the Rpcd daemon (as well as rpcbind) for some testing, but now I have to restart it since we are using VPO. The problem is that Rpcd won't start on the sever, while on another I had no problem at all with this action.
Starting Rpcd using the /etc/rc2.d/ script exits with a code 1.
Checking the /var/opt/dce/svc/fatal.log, I've got the following error:
2003-06-16-08:51:14.662+00:00I----- PID#3718 FATAL rpc general dgclive.c 488 0x00000001 (rpc__dg_maintain_init) Can't create UUID

Ok, so to see what exactly the problem is, I've typed the uuidgen command, its output is:
The uuid_create call failed with the following error:
No IEEE 802 hardware address (dce / rpc)

And now I'm stuck... Can anyblody help me with this problem? The idea is to have Rpcd running again (as it did before).
Thanks a thousand!

[Jean-Louis Phelix]

hi,

Perhaps you could try to recreate de dlpi devices :

root# insf -v -e -d dlpi

Regards.

[T G Manikandan]

Download the patches from

http://www1.itrc.hp.com/service/ciss/doLogin.do?TargetPage=http://www1.itrc.hp.com/service/patch/mainPage.do

Download them as a bundle and then

you can use 'swinstall' to intall the patch depot

[T G Manikandan]

sorry,
my above answer was to a different post.Please ignore

[Carlos André]

I've tried the insf command, but the uuidgen command still fails...

[T G Manikandan]

Can you find any errors using
#lanadmin

or check the /var/adm/syslog/syslog.log file

Revert

[Massimo Bianchi]

Hi,
just a thought: what else did you stop ?
Maybe you have stopped a service/demon rpc relay on... don't know exaclty which, althought.

HTH,
Massimo

[Carlos André]

As far as the stopped services are concerned:
I've stopped all MWA-related services (MeasureWare), rpc.ttdbserver, rpc.cmsd, recserv as well as all the little services such as echo, discard and so on... Portmap (rpcbind) has been disabled in /etc/services for a long time (doesn't prevent it from running though...).
I am using lsof | grep -i LISTEN to see what are the running services.

Regards

[Alex Glennie]

STRMSGSZ set from default ?

if yes set to 0 (unlimiited), regen kernel and try again ?

[Carlos André]

Concerning the STRMSGSZ kernel parameter, it is set to 65535 on the faulty server, but it is also set to the same value on the other server onto which I successfully managed to have rpcd to run again... Those two servers are alike (they are part of the same MC/SG cluster).
In a nutshell, I wouldn't want to modify a kernel parameter that used to work before stopping any service.

Please find below the remaining running services on this server, it may help or so I hope ;O)
(I've restarted a few previsouly halted services to check whether it would change somthing, but no luck...)

snmpdm
psmond
swagentd
sshd2
cmcld
cmlvmd
dtlogin
disk_em
dm_TL_adapter
dm_core_hw
dm_memory
lpmc_em
sysstat_e
dm_FCMS_a
cclogd
diaglogd
memlogd
psmctd
registrar
rpcbind
rpc.ttdbs
ttd
dtterm

[Alex Glennie]

.

out of interest try

entering into landiag in testmode and run 'l'

any errors ?

[Carlos André]

REPLY TO T G Manikandan concerning LANADMIN.
(I am sorry, I didn't catch your post this morning)
As I am not a lanadmin wizzard, I launched SAM and checked the Network interface module. When starting it, it says there is no LAN card configured on my system! For crying out loud...
The funny thing is that I can rlogin onto it and launch SAM in graphic mode.

BTW, no error found in syslog.log...

[Carlos André]

Ok, I've tried the lanadmin command, entering 'lan', it says "Unable to open device file /dev/dlpi", knowing that I've insf'd it this morning...

[Alex Glennie]

Darn I mean't lanadmin not landiag ....

Other things to check :

is rbootd running ? if yes try killing it

perms on /dev/dlpi

output from landiag testmode 'l'

[Carlos André]

lanadmin returns: ""Unable to open device file /dev/dlpi"

rights on /dev/dlpi: crw-rw-rw

... and rbootd isn't running.

what about removing /dev/dlpi, and run insf again?

ll /dev/dlpi* gives:
crw-rw-rw- 1 root sys 72 0x000077 Dec 11 2000 dlpi
crw-rw-rw- 1 root sys 119 0x000000 Dec 11 2000 dlpi0
crw-rw-rw- 1 root sys 119 0x000001 Dec 11 2000 dlpi1
crw-rw-rw- 1 root sys 119 0x000002 Dec 11 2000 dlpi2
crw-rw-rw- 1 root sys 119 0x000003 Dec 11 2000 dlpi3
crw-rw-rw- 1 root sys 119 0x000004 Dec 11 2000 dlpi4

[Alex Glennie]

My advise would be if you have a software support contract with HP log a call ... this looks a little interesting.

Failing that a reboot (I know) may resolve this or perhaps using lsof to take a closer look at the dlpi resources ....

ie I'm out of ideas on this one .....

[Carlos André]

Well Alex, you are a genius (but you may already know it?).
I've used lsof to see what's going on with those dlpi thingies... It appeared there were litterally hundreds of glance using it, and about 20 glance processes running (don't know where do those guys come from), so I killed all the glance processes, then re-run an lsof to see that scopeux was cannibalizing my dlpi as well, with 1 scopeux process running that I joyfully killed (you gotta like MWA...).
Anyway, after that, I could see my network cards again, and I could run my beloved rcpd again!

So Thanks a lot guys for your help, I really appreciate it!