Created attachment 354988 [details] lightly commented strace Description of problem: When starting mc there is a long delay between it really starts. By looking at strace jchadima clairvoyantly found that the issue is somewhere in the hostname resolution, when mc tries to resolve $(hostname -s).localdomain which doesn't exist. I can reproduce it on F11 with the below shown component, jchadima on freshly upgraded Rawhide Version-Release number of selected component (if applicable): mc-4.6.2-10.fc11.x86_64 glibc-2.10.1-2.x86_64 glibc-2.10.1-2.i686 How reproducible: 100% Steps to Reproduce: 1.run mc 2. 3. Actual results: observe a long delay before the window opens Expected results: mc should start instantenously Additional info:
Please try options single-request in /etc/resolv.conf (or, in rawhide glibc, also) options single-request-reopen Perhaps there is a buggy firewall in between your box and DNS server.
Nor options single-request nor options single-request-reopen helps. The time delay is almost the same. The problem is that mc tries to resolve the hostname $(hostname -s)."localdomain" which does not exist nor in local DNS server nor in the internet. There is no firewall between the host and DNS server. (On the host are iptables switched off and the DNS server have no host specific rules) This behavior is new for 1 or 2 weeks.
Neither of these options in /etc/resolv.conf makes any difference on F11. And note that I have no local domainserver (not even the caching-only one) and that other network related programs (firefox, gajim) work without a problem.
What do you get from "host -v $(hostname -s).localdomain"?
bradford:~# host -v $(hostname -s).localdomain hostname: Neznámý počítač host: '.localdomain' is not a legal name (unexpected end of input) bradford:~# cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 bradford.ceplovi.cz bradford.localdomain localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 66.187.229.252 vpn2.redhat.com 209.132.176.231 bugzilla.redhat.com 85.207.117.49 kaprova-server 90.178.67.135 doma-sit bradford:~# hostname bradford bradford:~# hostname -s hostname: Neznámý počítač bradford:~# ("Neznámý počítač" is "unknown computer" in Czech)
So it is a bug in mc that it uses the output of hostname -s without checking.
Could you please try to reproduce it again with 4.7.0-pre1 we have in rawhide now?
Using build from http://koji.fedoraproject.org/koji/taskinfo?taskID=1598069 the result is very same ... start of mc takes ages. (BTW, couldn't we get Changelog or NEWS in %docdir?)
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Long-time start of mc because own implementation of Samba have a some hostname resolving thinks in init stage. In not far future developers of mc will drop own samba stuff and will use libsmbclient via dlopen/dlsum/dlclose (for avoid additional rpm/deb/etc package requirements).
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I haven't seen this for a long time.