iPlanet causing "Poll failed" messages in syslog

[Sean OB_1]

I'm running iPlanet 6.0 service pack 5 on an HPUX 11i server.

We are getting the following in syslog:

Sep 10 08:47:10 cosmoweb2 uxwdog[26300]: Poll failed: nmsgs=-216, errno=216 (Soc
ket operation on non-socket)
Sep 10 08:47:10 cosmoweb2 above message repeats 22350115 times
Sep 10 08:47:10 cosmoweb2 uxwdog[26300]: Poll failed: nmsgs=-216, errno=216 (Soc
ket operation on non-socket)
Sep 10 09:07:10 cosmoweb2 uxwdog[26300]: Poll failed: nmsgs=-216, errno=216 (Soc
ket operation on non-socket)
Sep 10 09:07:10 cosmoweb2 above message repeats 21885097 times
Sep 10 09:07:10 cosmoweb2 uxwdog[26300]: Poll failed: nmsgs=-216, errno=216 (Soc
ket operation on non-socket)



Has anyone seen this before? Do you know what causes it?

Any thoughts on what I can do to try and track down what is causing this message? Searches on sunsolve, google, itrc come up with nothing.

Netstat shows everything looking pretty normal.

Lanadmin shows the following for the interface:

PPA Number = 0
Description = HP PCI 10/100Base-TX Core [100BASE-TX,FD,MANUA
L,TT=1500]
Type (value) = ethernet-csmacd(6)
MTU Size = 1500
Speed = 100000000
Station Address = 0x306e5ccf33
Administration Status (value) = up(1)
Operation Status (value) = up(1)
Last Change = 7984296
Inbound Octets = 1048368700
Inbound Unicast Packets = 41349799
Inbound Non-Unicast Packets = 15355887
Inbound Discards = 0
Inbound Errors = 3
Inbound Unknown Protocols = 11681947
Outbound Octets = 4283965110
Outbound Unicast Packets = 82281150
Outbound Non-Unicast Packets = 148822
Outbound Discards = 0
Outbound Errors = 0
Outbound Queue Length = 0
Specific = 655367


TIA,

Sean

[Massimo Bianchi]

Hi,
as a first thing i would use tusc to trace the calls during these erros.

Socket operation on non-socket

More: doing a search in itrc lead the following:

OOps, i found that was already you, at the 5 of june.


So, check traces with tusc remains my best guess.....

Massimo

[Steven E. Protter]

Finally, I can run a itrc search.

This thread leads to others and a possible solution.
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xa3720ea029a2d711abdc0090277a778c,00.html

SEP

[Massimo Bianchi]

Hi SEP, it was him at the 25 of june.... i also found that thread, but it lead no solution for him.

He is asking again for help

Massimo

[Steven E. Protter]

Others may have gotten a solution but not you. Or me.

So.

In a telnet/ssh window:
tail -f /var/adm/syslog.log

Then excersize the iplanet server. Make a written log of what you are doing and what time you are doing it. Use the clock on your server so the times are accurate. When you find correlation, at least you have somewhere to go.

If the server itself has logs, you may wish to monitor them in the same way.

The looks of this error is it relates to networking. Maybe check lanadmin and see if there are errors on the NIC card.

Take a look at your duplex status on the NIC and the switch, which should be not be autonegotiate unless you have a gigabit card.

SEP

[T G Manikandan]

Make sure that your duplex and speed settings are same at both ends i.e.switch port and server with auto_neg off.


From your server just do a

#lanadmin -x 0

Login into your switch and find the settings for that port.

Revert

[Sridhar Bhaskarla]

Hi Sean,

I believe it has nothing to do with the network. uxwdog is the process that stops/starts your web servers. You may want to stop and start the entire iplanet itself including uxwdog process.

-Sri

[U.SivaKumar_2]

Hi,

Increase these kernel parameters ( increase the value depending upon your server's free memory resources ) and reboot the new kernel.

maxfiles

maxfiles_lim

nfiles

regards,

U.SivaKumar.

[Sean OB_1]

Thanks for the replies everyone. I originally started looking at this back in June but then got pulled off to work on other things and am just now getting back to it.


We manually set all of our NICS to 100FD and all switch ports are set to 100FD. So that isn't the issue.

We manually restart the web server every night via the stop/start scripts provided by iPlanet.

This shuts down the uxwdog process and the iplanet servers nightly.

I'll look into the kernel parms recommended and let you know if we make a change with that.

[rick jones]

The syslog means pretty much what it says - that iPlanet attempted to perform a socket operation on a file descriptor that was not a socket. Likely as not, it implies an error in iPlanet.

The suggestion to tusc is good. You might have to tusc for a while to go back far enough to see the history of the file descriptor in question. Perhaps it called close() on a socket but didn't remember to clear that FD number from its poll list.

If increasing the number of file descriptors per process/system "fixes" the problem, it suggests that iPlanet isn't doing the right thing when it gets a previous error about a file descriptor not being available (which you may see in the tusc you take)

Indeed, no NIC or TCP or IP settings would likely have any bearing on the error message iPlanet is reporting.