abrams@cs.columbia.edu (Steven Abrams) (11/13/90)
I hoped someone "out there" might be able to help. I just inherited the management of a cluster of diskless 320's being served by a 350, running HP-UX 7.0. The problem is that the syslogd's on the clients are continuously spitting out informative messages of the form, "Nov 12 12:50:44 chamonix syslogd: select: Invalid argument" Note, chamonix is the name of the diskless node and select is the name of the server. This, of course, may be a coincedence and the message could be refering to the select system call. The syslog.conf file looks like: *.info /usr/adm/syslog *.alert /dev/console *.alert root *.emerg * I temporarily solved the problem by sending *.info messages to /dev/null, but this chewed up tons of CPU time. I have shut down the syslogd on the clients, but would prefer to keep it running if possible Anyone have any clues? Thanks, ~~~Steve -- /************************************************* * *Steven Abrams abrams@cs.columbia.edu * **************************************************/ #include <std/dumquote.h> #include <std/disclaimer.h>
rodean@hpfcdc.HP.COM (Bruce Rodean) (11/16/90)
In article <ABRAMS.90Nov12125516@division.cs.columbia.edu> abrams@cs.columbia.edu (Steven Abrams) writes: > I hoped someone "out there" might be able to help. I may be able to. I think you have some big configuration problems. > I just inherited the management of a cluster of diskless 320's being > served by a 350, running HP-UX 7.0. The problem is that the syslogd's > on the clients are continuously spitting out informative messages of > the form, "Nov 12 12:50:44 chamonix syslogd: select: Invalid argument" > > Note, chamonix is the name of the diskless node and select is the name > of the server. This, of course, may be a coincedence and the message > could be refering to the select system call. The syslog.conf file > looks like: I would say that the bogus information regarding server and client names coming from syslogd is the result of a bad /etc/rc file. Look for the function set_state in that file. It looks like the clients' hostnames are being set to the server's hostname. Syslogd in this case is printing out the time, the hostname, the status that a select system call failed, and that the error it got was EINVAL. You should also compare the /etc/rc file with the one in /etc/newconfig/rc. Check if anything is grossly different. > I temporarily solved the problem by sending *.info messages to > /dev/null, but this chewed up tons of CPU time. I have shut down the > syslogd on the clients, but would prefer to keep it running if possible > > Anyone have any clues? As far as to why you are getting the error in the first place, it is my guess that a socket() call is failing. The code (which is based upon BSD code) does no error cleanup in that case. When you get down to the select call (it waits for data to show up on /dev/log and the socket), you get an EINVAL error return. I think this is because the variable storing the networking file descriptor mask used for select is never set. From looking at the socket manual entry, the only two errors I think could occur are either: 1) Networking not started up This could be a result of a couple of things: a) The ifconfig command in /etc/netlinkrc is bad. Make certain that whatever 'hostname' is is in /etc/hosts. Since apparently your hostname is the same on the clients as on the server, I think you are in big trouble here, although I don't know all the consequences of this. If you are using an IP address instead, make sure it is valid. To check this, look at the output of ifconfig lan0 (or whatever device is being configured). It should report UP and give a valid IP address and netmask. b) If you are using a name resolver, make certain that /etc/netisr is running. This is a kernel process which runs if networking is in your kernel. 2) Out of memory problems This is somewhat unlikely, but execute netstat -m. If there are a bunch of requests denied at the problem, you are short on networking memory. Hope this helps. I will also mail this directly to you. Bruce Rodean rodean@hpfcla.FC.HP.COM This does not reflect the official position of Hewlett-Packard Co. It is supplied without warranty of any kind.