/var/adm/inetd.sec: cannot start any server

[D.K.Kannan]

Hi everyone,

I am getting the error displayed on console side that /var/adm/inetd.sec: cannot start any server, and in users side /usr/lib/dld.sl error.

My server configuration is HP K360/ Dual Processor with 180MHz/128MB Memory/ using LVM

All the users are logging to the server using the telnetd daemon.

Now the server is not allowing the user to login and even from console.

The only thing to do is reboot the server using the key.

Reply with solutions is highly appreciated.

With best regs,
Kannan

[James Murtagh]

Hi,

I have seen this before, i believe it was caused by having hostnames in /var/adm/inetd.sec which couldn't be resolved. I would boot to single user mode, mount /usr and /var and copy the default inetd.sec after moving the current one:

# mv /var/adm/inetd.sec /var/adm/inetd.sec.bad
# cp /usr/newconfig/var/adm/inetd.sec /var/adm/inetd.sec

You can then unmount the filesystems and reboot. This should at least allow users to login while you identify the problem.

Regards,

James.

[Michael Steele_2]

Biggest problem with inetd.sec is the wrap around of one line with the "\" forward slash character. In short, don't use and carriage returns with your updates.

[Michael Steele_2]

That was ANY!

Biggest problem with inetd.sec is the wrap around of one line with the "\" forward slash character. In short, don't use ANY carriage returns with your updates.

[Steven E. Protter]

I would back out the inetd.sec first.

Go through it make sure every hostname resolves. Get out every wrap linefeed.

I try and use IP addresses in there, that is very anal but it prevents problems when the garbage microsoft DNS servers go down.

Another possible cause is the /etc/resolv.conf file on the connecting servers. Does it point to valid DNS servers? Do those DNS servers actually resolve the hostnames in your inetd.sec file.

inetd.sec is a wonderful tool and I encourage everyone to use it. It makes using insecure protocols like telnet and ftp much safer by limiting access.

SEP

[T G Manikandan]

I would suggest to check the /var/adm/syslog/syslog.log file for any errors.

Probably it could also be due to some kernel parameter limitation.

Revert

[KCS_1]

hi,

I recommend this solution to install "tusc" program in your hpux from http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/tusc-7.3/

and then you can see tracing logs of your command(telnet or any commands) when you are excuting the command on hp-ux.

look at the tracing logs carefully.

have a good day!

[john korterman]

Hi,
same problem described in:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x7d6c42308663d611abdb0090277a778c,00.html
zpparently caused by a full inode table. After reboot execute bdf -i to check the "ifrees".

regards,
John K.