[Touch-packages] [Bug 94940] Re: mdns listed in nsswitch.conf causes excessive time for dns lookups
I would think that could potentially open you up to something bad. Say you have payroll.mydomain.local and I join my linux box 'named 'payroll'. Now someone goes to http://payroll.mydomain.local/ and it hits my box. Switching MDNS to the end (files dns mdns4_minimal [NOTFOUND=return]) should fix the issue in cases where DNS wasn't down for some reason. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/94940 Title: mdns listed in nsswitch.conf causes excessive time for dns lookups Status in avahi package in Ubuntu: Confirmed Status in nss-mdns package in Ubuntu: Confirmed Status in nss-mdns package in Debian: Fix Released Bug description: Binary package hint: avahi-daemon I encountered this problem on a machine that is integrated into our work network. I performed a dist-upgrade to Feisty on my desktop and all went well. I've noticed recently that any dns based work seemed to take a significantly longer time then normal. My system is getting dns information on our company internal systems from two dns servers. Previously, if I tried to establish an ssh connection with another system I could generally expect the connection in under 3 secs. After the dist-upgrade the time went from under 3 seconds to approximately 25 seconds. After searching around the system I found an entry in /etc/nsswitch.conf that cause me a little concern. The line in question is: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I looked around a bit and it seems that the references to mdns are really talking about communication with the Avahi mDNS/DNS-SD daemon. Since this looks to be a part of a zeroconf configuration I wasn't expecting too much in my current environment, as we really only have three Mac's. What concerned me is the idea that if we hit files with no answer there is a delay while we hit the other options until we hit dns, which is where the information I seek existed. For an experiment I tried two separate tests. The first changed the line to looks like: hosts: files dns mdns4_minimal [NOTFOUND=return] mdns The change should have improved the time, but I was still looking at approximately 23 seconds to return a command prompt on the destination machine. Finally, I change the entry to simply: hosts: files dns After this change I was again receiving the destination command prompt in under 3 seconds. I don't know if simply changing the file will correct the problem long-term or not. Seems to help me, but might be the way to go for most Ubuntu users. ProblemType: Bug Architecture: i386 Date: Thu Mar 22 18:10:54 2007 DistroRelease: Ubuntu 7.04 Uname: Linux samdesk 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 94940] Re: mdns listed in nsswitch.conf causes excessive time for dns lookups
By all means, go ahead and switch Kristian, although I ran into the same issue on a few Debian boxes I installed recently. I'd rather have mdns and avahi enabled by default because a lot of printers rely on them. I also don't want to have to answer additional questions during the install. Like many people have said above, the problem is due to a misconfiguration on your network. Don't use '.local' for your Windows domain. If you can't change your internal domain, there's an easy work- around that's documented above as well. Why should we break a commonly-used protocol because *your* network is mis-configured? Please stop whining about it and threatening to switch because it's not productive and doesn't have any bearing on solving the issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/94940 Title: mdns listed in nsswitch.conf causes excessive time for dns lookups Status in avahi package in Ubuntu: Confirmed Status in nss-mdns package in Ubuntu: Confirmed Status in nss-mdns package in Debian: Fix Released Bug description: Binary package hint: avahi-daemon I encountered this problem on a machine that is integrated into our work network. I performed a dist-upgrade to Feisty on my desktop and all went well. I've noticed recently that any dns based work seemed to take a significantly longer time then normal. My system is getting dns information on our company internal systems from two dns servers. Previously, if I tried to establish an ssh connection with another system I could generally expect the connection in under 3 secs. After the dist-upgrade the time went from under 3 seconds to approximately 25 seconds. After searching around the system I found an entry in /etc/nsswitch.conf that cause me a little concern. The line in question is: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I looked around a bit and it seems that the references to mdns are really talking about communication with the Avahi mDNS/DNS-SD daemon. Since this looks to be a part of a zeroconf configuration I wasn't expecting too much in my current environment, as we really only have three Mac's. What concerned me is the idea that if we hit files with no answer there is a delay while we hit the other options until we hit dns, which is where the information I seek existed. For an experiment I tried two separate tests. The first changed the line to looks like: hosts: files dns mdns4_minimal [NOTFOUND=return] mdns The change should have improved the time, but I was still looking at approximately 23 seconds to return a command prompt on the destination machine. Finally, I change the entry to simply: hosts: files dns After this change I was again receiving the destination command prompt in under 3 seconds. I don't know if simply changing the file will correct the problem long-term or not. Seems to help me, but might be the way to go for most Ubuntu users. ProblemType: Bug Architecture: i386 Date: Thu Mar 22 18:10:54 2007 DistroRelease: Ubuntu 7.04 Uname: Linux samdesk 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 94940] Re: mdns listed in nsswitch.conf causes excessive time for dns lookups
FYI - Microsoft KB296250 is the article where they recommend using '.local'. It was last updated in 2007. https://support.microsoft.com /en-us/kb/296250 RFC6762 describes the use of mDNS and the .local TLD. https://tools.ietf.org/html/rfc6762 While RFC6762 came after Microsoft's KB article, RFCs describe industry standards and best practices. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/94940 Title: mdns listed in nsswitch.conf causes excessive time for dns lookups Status in avahi package in Ubuntu: Confirmed Status in nss-mdns package in Ubuntu: Confirmed Status in nss-mdns package in Debian: Fix Released Bug description: Binary package hint: avahi-daemon I encountered this problem on a machine that is integrated into our work network. I performed a dist-upgrade to Feisty on my desktop and all went well. I've noticed recently that any dns based work seemed to take a significantly longer time then normal. My system is getting dns information on our company internal systems from two dns servers. Previously, if I tried to establish an ssh connection with another system I could generally expect the connection in under 3 secs. After the dist-upgrade the time went from under 3 seconds to approximately 25 seconds. After searching around the system I found an entry in /etc/nsswitch.conf that cause me a little concern. The line in question is: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I looked around a bit and it seems that the references to mdns are really talking about communication with the Avahi mDNS/DNS-SD daemon. Since this looks to be a part of a zeroconf configuration I wasn't expecting too much in my current environment, as we really only have three Mac's. What concerned me is the idea that if we hit files with no answer there is a delay while we hit the other options until we hit dns, which is where the information I seek existed. For an experiment I tried two separate tests. The first changed the line to looks like: hosts: files dns mdns4_minimal [NOTFOUND=return] mdns The change should have improved the time, but I was still looking at approximately 23 seconds to return a command prompt on the destination machine. Finally, I change the entry to simply: hosts: files dns After this change I was again receiving the destination command prompt in under 3 seconds. I don't know if simply changing the file will correct the problem long-term or not. Seems to help me, but might be the way to go for most Ubuntu users. ProblemType: Bug Architecture: i386 Date: Thu Mar 22 18:10:54 2007 DistroRelease: Ubuntu 7.04 Uname: Linux samdesk 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 94940] Re: mdns listed in nsswitch.conf causes excessive time for dns lookups
With all due respect +thejranjan, it's not really Ubuntu's fault. Microsoft recommended for years that companies use '.local' as their internal domain suffix so as not to conflict with the existing DNS namespace like .com, .net, .org, etc... Unfortunately Microsoft just decided to recommend .local without thinking it through or registering .local with any standards body. Later on a standards body decided to use .local for Multicast DNS. So you run into this problem when you connect your Ubuntu box (and I believe Debian as well) to a Microsoft Windows network that *violates* established standards. The fix is easy enough--edit /etc/nsswitch.conf and remove multicast DNS. That gives you access to your internal network which is configured improperly. Unfortunately you might have trouble communicating with multicast DNS services. A work-around is to remove the '[NOTFOUND=return]' part of the mdns config. That basically tells the system to try looking up from multicast DNS and immediately fail if multicast DNS doesn't find anything. If you remove it, you will still have delays looking up hosts on your internal network, but you *will* get the best of both worlds-- multicast DNS resolution *and* resolution of your incorrectly-named internal network. So there's nothing really for Ubuntu to fix. It's up to you to fix your internal network or make a change to your Ubuntu install so it can communicate with your improperly configured internal network. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/94940 Title: mdns listed in nsswitch.conf causes excessive time for dns lookups Status in avahi package in Ubuntu: Confirmed Status in nss-mdns package in Ubuntu: Confirmed Status in nss-mdns package in Debian: Fix Released Bug description: Binary package hint: avahi-daemon I encountered this problem on a machine that is integrated into our work network. I performed a dist-upgrade to Feisty on my desktop and all went well. I've noticed recently that any dns based work seemed to take a significantly longer time then normal. My system is getting dns information on our company internal systems from two dns servers. Previously, if I tried to establish an ssh connection with another system I could generally expect the connection in under 3 secs. After the dist-upgrade the time went from under 3 seconds to approximately 25 seconds. After searching around the system I found an entry in /etc/nsswitch.conf that cause me a little concern. The line in question is: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I looked around a bit and it seems that the references to mdns are really talking about communication with the Avahi mDNS/DNS-SD daemon. Since this looks to be a part of a zeroconf configuration I wasn't expecting too much in my current environment, as we really only have three Mac's. What concerned me is the idea that if we hit files with no answer there is a delay while we hit the other options until we hit dns, which is where the information I seek existed. For an experiment I tried two separate tests. The first changed the line to looks like: hosts: files dns mdns4_minimal [NOTFOUND=return] mdns The change should have improved the time, but I was still looking at approximately 23 seconds to return a command prompt on the destination machine. Finally, I change the entry to simply: hosts: files dns After this change I was again receiving the destination command prompt in under 3 seconds. I don't know if simply changing the file will correct the problem long-term or not. Seems to help me, but might be the way to go for most Ubuntu users. ProblemType: Bug Architecture: i386 Date: Thu Mar 22 18:10:54 2007 DistroRelease: Ubuntu 7.04 Uname: Linux samdesk 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1389356] Re: rsyslogd stops responding, doesn't log data, and eventually hangs the system
Er. Apparently it's a feature, not a bug. "rsyslog was still a running process, it just stopped logging both remotely and to local files. We found a few discussions of this problem from 2012, 2011 and 2009 but they didn’t entirely cover the problem. However, the common thread was a connectivity issue causing problems with the queuing. Although not definitive, that every server in just one of our data centres saw this problem gave weight to a network based issue which may have caused rsyslog to hang for all actions, even though it was a network issue and we still had disk based logging enabled. After discussing the issue with the Papertrail support guys, in order to combat this we decided to enable reliable f0rwarding which means rsyslog will queue log lines in memory and then to disk if the remote server cannot be reached, posting them when connectivity returns. This is necessary because syslog over TCP is not entirely reliable" (See https://blog.serverdensity.com/reliable-forwarding-with-rsyslog/) ** Changed in: rsyslog (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1389356 Title: rsyslogd stops responding, doesn't log data, and eventually hangs the system Status in “rsyslog” package in Ubuntu: Invalid Bug description: This is happening on a wide variety of client systems that are all dissimilar--some are virtual machines, some are physical machines, and it spans 11.04, 12.04, 13.10, and 14.04. It started about two months ago. Approximately once per week, we will start getting calls from all our clients that services running on linux boxes are unavailable or extremely slow. Attempts to access the boxes via SSH will either not work (hang and then timeout after ~2 minutes) or succeed (after hanging for ~1 minute). Then the shell prompt takes a while (maybe 30 seconds) to display. After spending several frustrating hours with one particular box, I noticed the following: * Very low disk IO (i.e. the box isn't hammering the disk) * Memory usage was appropriate * Network IO was appropriate and responsive (ping, traceroute, wget, etc...) * Logs were all 'empty'. Last log data was in the log from the previous evening (i.e. /var/log/syslog.1 has a final entry at 8:36 PM PST from the previous night) Running the command 'restart rsyslogd' immediately returns the box to normal operation. After a few more testing sessions, I can see that rsyslogd is running on all these boxes, it just appears to be unresponsive. The issue happens fairly regularly--every 7-10 days, and it happens on multiple disparate systems on different networks at approximately the same time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1389356/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1389356] [NEW] rsyslogd stops responding, doesn't log data, and eventually hangs the system
Public bug reported: This is happening on a wide variety of client systems that are all dissimilar--some are virtual machines, some are physical machines, and it spans 11.04, 12.04, 13.10, and 14.04. It started about two months ago. Approximately once per week, we will start getting calls from all our clients that services running on linux boxes are unavailable or extremely slow. Attempts to access the boxes via SSH will either not work (hang and then timeout after ~2 minutes) or succeed (after hanging for ~1 minute). Then the shell prompt takes a while (maybe 30 seconds) to display. After spending several frustrating hours with one particular box, I noticed the following: * Very low disk IO (i.e. the box isn't hammering the disk) * Memory usage was appropriate * Network IO was appropriate and responsive (ping, traceroute, wget, etc...) * Logs were all 'empty'. Last log data was in the log from the previous evening (i.e. /var/log/syslog.1 has a final entry at 8:36 PM PST from the previous night) Running the command 'restart rsyslogd' immediately returns the box to normal operation. After a few more testing sessions, I can see that rsyslogd is running on all these boxes, it just appears to be unresponsive. The issue happens fairly regularly--every 7-10 days, and it happens on multiple disparate systems on different networks at approximately the same time. ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1389356 Title: rsyslogd stops responding, doesn't log data, and eventually hangs the system Status in “rsyslog” package in Ubuntu: New Bug description: This is happening on a wide variety of client systems that are all dissimilar--some are virtual machines, some are physical machines, and it spans 11.04, 12.04, 13.10, and 14.04. It started about two months ago. Approximately once per week, we will start getting calls from all our clients that services running on linux boxes are unavailable or extremely slow. Attempts to access the boxes via SSH will either not work (hang and then timeout after ~2 minutes) or succeed (after hanging for ~1 minute). Then the shell prompt takes a while (maybe 30 seconds) to display. After spending several frustrating hours with one particular box, I noticed the following: * Very low disk IO (i.e. the box isn't hammering the disk) * Memory usage was appropriate * Network IO was appropriate and responsive (ping, traceroute, wget, etc...) * Logs were all 'empty'. Last log data was in the log from the previous evening (i.e. /var/log/syslog.1 has a final entry at 8:36 PM PST from the previous night) Running the command 'restart rsyslogd' immediately returns the box to normal operation. After a few more testing sessions, I can see that rsyslogd is running on all these boxes, it just appears to be unresponsive. The issue happens fairly regularly--every 7-10 days, and it happens on multiple disparate systems on different networks at approximately the same time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1389356/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1389356] Re: rsyslogd stops responding, doesn't log data, and eventually hangs the system
...so I guess I'd like to know what I can do now to try and track down the issue. Is there a way I can grab information on the hanged rsyslogd process to find out what's going on? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1389356 Title: rsyslogd stops responding, doesn't log data, and eventually hangs the system Status in “rsyslog” package in Ubuntu: New Bug description: This is happening on a wide variety of client systems that are all dissimilar--some are virtual machines, some are physical machines, and it spans 11.04, 12.04, 13.10, and 14.04. It started about two months ago. Approximately once per week, we will start getting calls from all our clients that services running on linux boxes are unavailable or extremely slow. Attempts to access the boxes via SSH will either not work (hang and then timeout after ~2 minutes) or succeed (after hanging for ~1 minute). Then the shell prompt takes a while (maybe 30 seconds) to display. After spending several frustrating hours with one particular box, I noticed the following: * Very low disk IO (i.e. the box isn't hammering the disk) * Memory usage was appropriate * Network IO was appropriate and responsive (ping, traceroute, wget, etc...) * Logs were all 'empty'. Last log data was in the log from the previous evening (i.e. /var/log/syslog.1 has a final entry at 8:36 PM PST from the previous night) Running the command 'restart rsyslogd' immediately returns the box to normal operation. After a few more testing sessions, I can see that rsyslogd is running on all these boxes, it just appears to be unresponsive. The issue happens fairly regularly--every 7-10 days, and it happens on multiple disparate systems on different networks at approximately the same time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1389356/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
