Inetd on an rx2660 running 11.31 will not start

[Ian Patterson]

Hello there, I have a problem with an ia64 rx2660 itanium server in that the inetd daemon will not start. I do a grep on the inetd and it presents as follows;
inetd -l
I do a /sbin/init.d/inetd stop and this returns
Internet Services stopped however when I grep for inetd the following is still present;
inetd -l
I then do /sbin/init.d/inetd start and this returns;
An Inetd is already running
Usage: inetd [-a] [-p proc_limit] [-r count [interval]] [-l | -s] inetd -c inetd -k
EXIT CODE: 255
Unable to start Internet Services

Can you offer some suggestions here for me to try, nfs is still going and remote console is still active but no rlogin or telnets

[Steven E. Protter · Accepted solution]

Shalom,

ps -ef | grep inet

See if there is a process.

man inetd

See the start/stop options/

vi /etc/inetd.conf

Lets see how its configured.

SEP

[Ian Patterson]

Thanks for responding so quickly
The /etc/inetd.conf has the following enabled
ftp stream tcp6 nowait root /usr/lbin/ftp ftpd -l

telnet stream tcp6 nowait root /usr/lbin/telnetd telnetd

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

login stream tcp6 nowait root /usr/lbin/rlogind rlogind

shell stream tcp6 nowait root /usr/lbin/remshd remshd

exec stream tcp6 nowait root /usr/lbin/rexecd rexecd

ntalk dgram udp wait root /usr/lbin/ntalks ntalkd

auth stream tcp6 wait bin /usr/lbin/identd identd

printer stream tcp nowait root /usr/sbin/rlpdaemon rlpdaemon -i

daytime stream tcp6 nowait root internal
daytime dgram udp6 nowait root internal
time stream tcp6 nowait root internal
echo stream tcp6 nowait root internal
echo dgram udp6 nowait root internal
discard stream tcp6 nowait root internal
discard dgram udp6 nowait root internal
chargen stream tcp6 nowait root internal
chargen dgram udp6 nowait root internal

kshell stream tcp6 nowait root /usr/lbin/remshd remshd -k

klogin stream tcp6 nowait root /usr/lbin/rlogind rlogind -k

swat stream tcp nowait.400 root /opt/samba/bin/swat swat
recserv stream tcp nowait root /usr/lbin/recserv recserv -display :0
registrar stream tcp6 nowait root /etc/opt/resmon/lbin/registrar /etc/opt/resmon/lbin/registrar
tftp dgram udp wait root /usr/lbin/tftpd tftpd\

/opt/ignite\
/var/opt/ignite
omni stream tcp nowait root /opt/omni/lbin/inet inet -log /var/opt/omni//log/inet.log
instl_boot dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd

These are the active lines in the inetd.conf

[Suraj K Sankari]

Hi,

What is the output of
ps -aef | grep -i inetd

is there any thing you can see in your /var/adm/syslog/syslog.log file.


Suraj

[Ian Patterson]

ps -aef|grep -i inetd shows;
root 11342 10408 0 16:02:41 console 0:00 grep -i inetd

root 10635 1 0 Apr 13 ? 0.00 inetd -l

The last bits of the syslog.log are as follows;
Apr 13 08:03 hporap26 inetd 3868 going down on signal 15
Apr 13 08:05:50 hporap26 inetd connection logging enabled
Apr 13 08:05:50 hporap26 inetd Reading configuration
---but it does not complete---

Ian

[Ivan Krastev]

Try to kill that inetd process and start it again via /sbin/init.d/ script.


regards,
ivan

[Ian Patterson]

well I had tried this before but running the command from /sbin/init.d made no difference.

Rebooting the server does not help either since the server boot calls to start the inetd and it hangs just as before.

doing a /sbin/init.d/inetd stop
states that the Internet Services Stopped
but a grep of the inetd still shows the pervasive process as follows;
ps -ef|grep inetd
root 10635 1 0 Apr 13 ? 0:00 inetd -l

running the restart produces the following as before;

/sbin/init.d/inetd start
An inetd is already running
Exit Code: 255
Unable to start Internet services

Lets know if you think of something else to try.

Ian

[Ivan Krastev]

Arm yourself with tusc - http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-8.0/

and check what exacly happens when you are trying to start the inetd daemon.

regards,
ivan

[Horia Chirculescu]

Hello Ian,

Try to kill the running daemon:

kill -9 10635

In order to simplify things, empty the syslog.log (if you need to save the log you can copy this file elsewhere first)

> /var/adm/syslog/syslog.log

Next, start again inetd

/sbin/init.d/inetd start

Post here the content of syslog:

cat /var/adm/syslog/syslog.log

Best regards from Romania,

Horia.

[S. Ney]

Ian,

Do you have bastille or the security containment extensions bundle configured?
http://docs.hp.com/en/5992-5804/ch08s07.html

Also is inetd turned on in /etc/rc.config.d/netdaemons?

[Ian Patterson]

Thanks for all the input so far still no success though its very frustrating since I can see that the cron is working and all is well with the server otherwise from the remote console access I have.
I am looking at the tusc option suggested, I have tried to kill the process but it wont die, I don't have bastille configured.
Inetd is turned on in the /etc/rc.config.d/netdaemons as follows;
export INETD=1
export INETd_ARGS=""

It is a sw issue alright I cant help but think it is a kernel issue though since all of the regular files and settings are as they should be. The server had not been rebooted for 500days so something has changed alright to stop the inetd from starting as it should.

Ian

[TTr]

Edit the inetd.conf and comment out all unecessary services. Comment out everything except a few well behaved services such as telnet and ftp.

Ensure that the hang inetd is killed (reboot the server if you can not kill the hang inetd)

Start inetd (or boot the server) with minimal inetd.conf. See if it starts that way.

[Horia Chirculescu]

>I have tried to kill the process but it wont die,

Do you get something in syslog.log when you are trying to kill the inetd server?

How did you tried to kill syslogd? Did you used -9 option:

ps -e|grep inetd
kill -9


Horia.

[Horia Chirculescu]

>to kill syslogd

errata:

to kill inetd

Horia.

[Ian Patterson]

hello there,
Well the server never completes a load of the inetd it hangs when reading the configuration and then when you grep for the inet you see that it is stuck on inetd -l this then is where everything stops you cannot kill the running process and cutting down the inetd.conf to minimilastic levels makes no difference still no proper inetd process so no rlogin or telnet access is possible while in this state.

[Horia Chirculescu]

>it is stuck on inetd -l this then is where everything stops you cannot kill the running process

-l means enable logging. What info do you get from /var/adm/syslog/syslog.log ?

Are you sure that you can not kill the running inetd with kill -9 ?

Be aware of the fact that inetd -k is trying to kill "gracefully" the daemon and can fail.

Horia.

[Ian Patterson]

Well after rebooting the server I can now kill off the inetd and stop and start but it still does not allow for remote logins and telnet or ftp.

Fortunately I do have NFS the filesystems have been linked to where they are needed as a work around.

There are some patches that have been recommended to install and this is happening on Sunday these being PHKL_38040, 38681,38691,38708,38737,39028,39397,39398,39399,39400,39464,39465,39476,39479,39482,39606,39740,40022,40224,40293,40434

So we wil see if this makes any difference.

[Steven Schweda]

> [...] does not allow for remote logins and
> telnet or ftp.

Not a useful problem description. What,
exactly, did you try, and what, exactly,
happened when you tried it?

Interesting stuff in the system log file(s)?

[Ian Patterson]

there was nothing really I could do except organise a time for the server to be rebooted. The only effect this had was to free up the locked inetd process but apart from this clearing the ability to at least kill the inetd and attempt to start and stop not change has been made.

We still do not get rlogin or telnet and as for being not useful well this is the nature of the problem and nothing I can do about that.

[Steven Schweda]

> We still do not get rlogin or telnet [...]

I don't know what that means.

> [...]and as for being not useful well this
> is the nature of the problem and nothing I
> can do about that.

How did you determine "the nature of the
problem"? Did you run some actual commands?
Did you get some actual results? Could you
show us any of that? That would be more than
"nothing".

You might begin with "uname -a".

[Ian Patterson]

ok I will try and be more specific for you but if you had been following the outputs you would see that no change to the original problem has occurred. NOONE can rlogin or telnet to the server the only access is through remote console and NFS

Apart from rebooting the server running /sbin/init.d/inetd stop and /sbin/init.d/inetd start but still no proper inetd access at this stage.
This may change after the nominated patches have been loaded running uname has no relevance to this issue.

[Steven Schweda]

> [...] but if you had been following the
> outputs you would see [...]

What I wouldn't see is anything like a useful
description of the actual problem. You may
think that you're providing useful
information, but you're not. A useful
problem description here would include some
actual commands with the resulting actual
error messages, not your description or
interpretation of them. "NOONE can" is not
a useful description of anything.

Try that newfangled copy+paste technology and
provide a transcript of an actual session,
showing an actual command and an actual
error message, and then we might be able to
get somewhere. Believe it or not, there are
many different types of problem which can
prevent a Telnet connection from working.
Many of them produce distinctive error
messages, but they're of little value to a
non-psychic like me unless you reveal them.

[Horia Chirculescu]

>rebooting the server running /sbin/init.d/inetd stop and /sbin/init.d/inetd start

Are you saying that the server reboots when you restart inetd?

Horia.

[Steven Schweda]

> [...] running uname has no relevance to
> this issue.

Yeah. Who might possibly care which version
of the OS you're running?

I've been sitting here trying to think of
something with less value than your opinion
of the relevance of any fact, but I'm not
coming up with much. I'll sleep on it, and
let you know if something comes to me.

[Ian Patterson]

Hello there I have to say first up that getting upset will not solve anything so can we leave the emotional crap out of this please.

Symptoms; The server an rx2660 was operating normally and well until a SAP patch was introduced requiring a server reboot the server had been up for just on 554 days and so anythingcould have happened to the kernel during that time.

When the server was rebooted the first time no inetd was active and the inet process appearred to be hung on reading the configuration and not completing the was shown with the syslog output. The server was then reported inetd -l in the process list and no remote connection was possible i.e. no telnet access and no rlogin access as explained earlier.

The inetd now appears to be running but not working.

the server outputs from uname -a are as follows;
HP-UX hporap26 B.11.31 U ia64 4114619928 unlimited-user license

The server has been up on its current kernel for 6 days now.

Crontab is working and all internal activities normally associated with the server are operational with the exception of the inetd process as I do a daily sysinfo report and the output of this is sitting in /tmp but without the inetd properly running the only way I can get to this info is via nfs.

It does seem strange but I would have thought is an extreem measure to consider rebuilding the server because of this but is would seem that unless a solution is found either I continue on with this limited access or rebuild and given the sensitivity of the SAP data I dont think the powers that be will agree to a rebuild because normal system access is disrupted. Currently no user or SAP application is affected by this inetd problem.

If there is nothing further you want or can advise then saying the problem cannot be fixed is an acceptable answer so lets here back what you want to look at if you want to explore this issue further.

The issue is really annoying and I did wonder if someone else out there had a similar problem and resolved it.

I don't mind sharing but could we limit the responses to points and leave out the crap after all it the solution that is important here not the style or window dressing to get to it !!!