I just started noticing a problem when a took a local LDAP server and moved it to a T1 at a local data center. Logins with KDE take a minute or longer. When I ping machines by name at this particular data center, there are several seconds between responses, but replies are 100%. I try the same ping by name from a local Windows server and no delay at all. Both machines use the same DNS, primary on the Windows server and secondary from a local RedHat 7.3 server. I can ping by IP from my SuSE workstation and no delay. I think the root of this problem is causing my slow logins, etc. I also have wait times when opening a terminal or file browser. Anybody know where I can look for this to work. In case it had something to do with my local hosts file, I change the search order to DNS, then the hosts file. No change. I generally get faster traceroutes to the data center from the Windows server compared to my local SuSE workstation. If anyone wants to try to their response times, there is a FreeBSD server at the data center at directory.webtent.net. If I do an ldapsearch of that directory, takes several seconds before it kicks back records. On another Linux box, response is almost immediate :\ -- Robert
On Saturday 24 January 2004 08:43, Robert Fitzpatrick wrote:
I just started noticing a problem when a took a local LDAP server and moved it to a T1 at a local data center. Logins with KDE take a minute or longer. When I ping machines by name at this particular data center, there are several seconds between responses, but replies are 100%. I try the same ping by name from a local Windows server and no delay at all. Both machines use the same DNS, primary on the Windows server and secondary from a local RedHat 7.3 server. I can ping by IP from my SuSE workstation and no delay. I think the root of this problem is causing my slow logins, etc. I also have wait times when opening a terminal or file browser. Anybody know where I can look for this to work. In case it had something to do with my local hosts file, I change the search order to DNS, then the hosts file. No change. I generally get faster traceroutes to the data center from the Windows server compared to my local SuSE workstation. If anyone wants to try to their response times, there is a FreeBSD server at the data center at directory.webtent.net. If I do an ldapsearch of that directory, takes several seconds before it kicks back records. On another Linux box, response is almost immediate :\
-- Robert
Robert: Paragraphs were invented for a reason. Please use them. Probably you have stale dns records somewhere between you and this data center. Most often a reboot the offending box it will improve. 1st you should compare the dns servers used by the fast windows box and the slow linux box and see if they are IN FACT the same. Second, restart or shutdown the nscd. Also if you are running bind locally you want to double check its configuration. -- _____________________________________ John Andersen
On Saturday 24 January 2004 12:35 pm, John Andersen wrote:
On Saturday 24 January 2004 08:43, Robert Fitzpatrick wrote:
I just started noticing a problem ... Logins with KDE take a minute or longer. When I ping machines by name at this particular data center, there are several seconds between responses, but replies are 100%. I try the same ping by name from a local Windows server and no delay at all. [snip]
Paragraphs were invented for a reason. Please use them.
without trying to be snide, I'll add a "ditto" to that -- you ended up writing so much people tend to focus on the last part and may miss the important point you made at the start: THERE ARE SEVERAL SECONDS BETWEEN RESPONSES for the linux machine, but not the windows machine. I think [but could be wrong] that this effectively eliminates any "DNS" problems because I don't believe there is a DNS lookup FOR EACH ping. The general rule-of-thumb is that you evaluate the user input, and if it is a direct IP address you use it; if not, you perform one lookup and remember that for later connection attempts, but I'm digressing If you had said "there is a pause for several seconds before the first ping returns, but then it proceeds normally" I'd be inclined to follow the DNS path. but with several seconds between EACH ping, I'd look at the hardware [such as the switch] and I'd start checking to see if perhaps another machine is configured with the same IP or MAC address as your linux machine [same IP can be pretty common, same MAC is rather difficult, but not impossible] network analyzers like ethereal are good for tracking down these types of problems. check cabling -- try swapping the cable/port used by the windows machine for the one on the linux machine and see if the problem follows the cable or the port Check to see if you are getting "errors" on your network interface -- the command "ifconfig" will report this as follows: bigbro:~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:40:F4:6E:4D:22 inet addr:192.168.40.2 Bcast:192.168.40.255 Mask:255.255.255.0 inet6 addr: fe80::240:f4ff:fe6e:4d22/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:402169 errors:0 dropped:0 overruns:0 frame:0 TX packets:372014 errors:0 dropped:0 overruns:5 carrier:0 collisions:0 RX bytes:171030817 (163.1 Mb) TX bytes:56593843 (53.9 Mb) Those last three lines are what you are looking for -- heavy errors are never good. Finally [and this is a bit of a stretch], how are the interrupts on your system? Look at the pseudo-file /proc/interrupts and look for your network device. do "some" activity, and look again -- do the numbers seem reasonable for the amount of traffic generated? Some of the >ahem< low-end network cards are "win-lan" cards [think "winmodem"] and rely heavily on the CPU -- I have one that would regularly crash my 100mhz file server, but worked fine in my 466mhz "client" computer
1st you should compare the dns servers used by the fast windows box and the slow linux box and see if they are IN FACT the same.
Actually, the first thought that came to mind [back on the DNS front] was to make sure that the windows machine doesn't have it's address cached locally or in a local "hosts" file. -- Yet another Blog: http://osnut.homelinux.net
Every time I run KPPP on SUSI I get the following message: /etc/resolv.conf is missing or can't be read! Ask your system administrator to create this file (can be empty) with appropriate read and write permissions. I create the file from root and KPPP works fine until I close it and re-open it at which time I get the same message. Upon installation of SUSI I was warned the first time I ran KPPP that I must make sure that /usr/sbin/pppd was owned by root and the SUID bit was set. This I did from the file manager being unsure how to set it otherwise ... presumably with chmod??? This is a pain in the butt. Any suggestions? I never had these kinds of problems with Mandrake or Red Hat. H.W.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
/etc/resolv.conf should be owned by root and in root's group. Permision
should be rw by owner, read by group and others.
- --
Jerry Feldman
On Sunday 25 January 2004 17:24, Stone Tool wrote:
Every time I run KPPP on SUSI I get the following message:
/etc/resolv.conf is missing or can't be read! Ask your system administrator to create this file (can be empty) with appropriate read and write permissions.
I create the file from root and KPPP works fine until I close it and re-open it at which time I get the same message. I, too, had that problem. I finally just reinstalled the whole thing and never saw that error, again. My first hint, though, that something was amiss was when installation never created a user: 'root' was all there was. :-\
Upon installation of SUSI I was warned the first time I ran KPPP that I must make sure that /usr/sbin/pppd was owned by root and the SUID bit was set. This I did from the file manager being unsure how to set it otherwise ... presumably with chmod???
Ditto, this pppd thing. After I created the new user from 'root' I constantly had to reset the suid from su. Sometimes it would stay set for more than one logon, sometimes not. Reinstallation cured this --for me, anyhow. Hope someone else has a better idea but if not...
This is a pain in the butt. Any suggestions? I never had these kinds of problems with Mandrake or Red Hat.
I, too, ran RH & Mandrake. Mdk was my distro of choice, at the time, and it
seemed to avoid these problems. RH, ditto. Not certain why SuSE is doing
this but I think SuSE is my distro of choice ...not withstanding these
problems. Once I had a good installation things went like clockwork.
The Sunday 2004-01-25 at 16:24 -0700, Stone Tool wrote:
Every time I run KPPP on SUSI I get the following message:
/etc/resolv.conf is missing or can't be read! Ask your system administrator to create this file (can be empty) with appropriate read and write permissions.
I create the file from root and KPPP works fine until I close it and re-open it at which time I get the same message.
Known problem. Don't let it be empty: put at least a comment on it. -- Cheers, Carlos Robinson
On Sunday 25 January 2004 11:56 pm, Carlos E. R. wrote:
The Sunday 2004-01-25 at 16:24 -0700, Stone Tool wrote:
Every time I run KPPP on SUSI I get the following message:
/etc/resolv.conf is missing or can't be read! Ask your system administrator to create this file (can be empty) with appropriate read and write permissions.
I create the file from root and KPPP works fine until I close it and re-open it at which time I get the same message.
Known problem. Don't let it be empty: put at least a comment on it.
Uhhhhh....... You all are confusing me. I don't get an /etc/resolv.conf until after my ppp connection is established. Put there by ip-up and gets it from /etc/ppp/resolv.conf I believe. Goes away as soon as the connection is closed. Works fine that way. Bob S.
El 2004-01-26 a las 23:05 -0500, Bob S. escribió: You forgot to email the list.
On Sunday 25 January 2004 11:56 pm, Carlos E. R. wrote:
The Sunday 2004-01-25 at 16:24 -0700, Stone Tool wrote:
Every time I run KPPP on SUSI I get the following message:
/etc/resolv.conf is missing or can't be read! Ask your system administrator to create this file (can be empty) with appropriate read and write permissions.
I create the file from root and KPPP works fine until I close it and re-open it at which time I get the same message.
Known problem. Don't let it be empty: put at least a comment on it.
Uhhhhh.......
You all are confusing me. I don't get an /etc/resolv.conf until after my ppp connection is established. Put there by ip-up and gets it from /etc/ppp/resolv.conf I believe. Goes away as soon as the connection is closed. Works fine that way.
Yes, that how it works. Assume the file exists, but it is empty (before connecting). During the connection, a backup is made (in /etc/ppp/resolv.conf), and the original is replaced by another one, non-empty, appropiate for the current connection (it is generated from data received from you r ISP during connection negotiation). When this goes down, the original file is copied back to /etc - but if it was empty, then it will be simply deleted. This works... except if you are using kppp (or some versions of it) that balks if the file is not there. To solve this the workaround is to have a file with a comment on it, no data. Then it is not deleted, and everybody is happy :-) -- Saludos Carlos Robinson
participants (8)
-
Bob S. -
C Hamel -
Carlos E. R. -
Jerry Feldman -
John Andersen -
Robert Fitzpatrick -
Stone Tool -
Tom Emerson