Hello and welcome to CertForums.co.uk, here we host free active certification forums with links to the best free resources for Microsoft's MCSA MCSE MCDBA Cisco's CCNA CCDA and CCNP, and CompTIA's A+ Network+ i-NET+ and Security+ certifications in the UK. If you wish to post or use other advanced features you will need to register first. Registration is absolutely free and takes only a few minutes to complete so sign up today!
If you have any problems with the registration
process or your account login, please contact support
We have an rs6000 at work that is giving us fits right now. Anyone with any rs6000 knowledge? Like where are the logs located? How is the file structure put together? I don't have access to the machine and I'm trying to talk someone else through it.
Behold, the turtle. He makes progress only when he sticks his neck out.
We have an rs6000 at work that is giving us fits right now. Anyone with any rs6000 knowledge? Like where are the logs located? How is the file structure put together? I don't have access to the machine and I'm trying to talk someone else through it.
It's a good link, Mitz. Unfortunately it doesn't help me with where things are stored. If I could just use the commands it shows from the console I could probably figure something out from that, but unfortunately I can't.
Behold, the turtle. He makes progress only when he sticks his neck out.
Logs are usualy in /var/log (from memory) - but check the settings in syslog.conf.
Harry.
”
Thanks Harry. That was my first suggestion, but I was told over the phone that the logs don't exist there. The guy I'm having to talk through things is not very patient with having to work from a command line and doesn't seem to "get" how to explore a file system.
The problem is that telnet.d is taking forever to respond to requests. It's taking a minute or more to respond client requests and in the meanwhile it is spawning process after process. It's configured so that inetd listens for requests and then calls telnet.d.
Taking a look at network traffic the TCP handshake goes normally. Then the clent asks for a session, the rs6000 sends an ack to that, and then it waits for what seems like almost forever before it opens the session.
Behold, the turtle. He makes progress only when he sticks his neck out.
If it is spawning a lot of processes doing that then something has been set up oddly.
You need to look at inetd.conf to see just what is happening there. It *may* be that wrappers have been enabled, and they are trying to do something clever that no longer works.
Another favourite for delays is a setting in resolv.conf pointing to resolvers that are no longer there.
The logs can also be in /var/adm - but the basic key to this is in syslog.conf.
If it is spawning a lot of processes doing that then something has been set up oddly.
You need to look at inetd.conf to see just what is happening there. It *may* be that wrappers have been enabled, and they are trying to do something clever that no longer works.
Another favourite for delays is a setting in resolv.conf pointing to resolvers that are no longer there.
The logs can also be in /var/adm - but the basic key to this is in syslog.conf.
Harry.
”
Thanks, Harry.
This is something that's been working fine until today. The problem just started this morning with no one making any configuration changes. I suppose it's possible that a configuration got corrupted so I'll have them redo those settings.
Behold, the turtle. He makes progress only when he sticks his neck out.
Hm - it could be. My guess is that something elsewhere that things depended on for resolving went away, hence the delays.
This sounds like a lookup timeout.
Harry.
”
Well, Harry, as usual you were right on the money.
DNS resolution was failing and I traced it down to not getting any responses back. The replies from the name servers were being stopped at the firewall. I don't know what changed, but I had the guy I was helping edit the routing table on the rs6000 to point to our other gateway and everything started working immediately. Why the one firewall/gateway started dropping rather than forwarding the dns replies to their point of origin to that one machine I haven't a clue, but that's what happened. All other machines that use dns servers accessed through that gateway are still working fine.
Behold, the turtle. He makes progress only when he sticks his neck out.