Bug 912530
| Summary: | Midnight Commander slow to start | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Piscium <groknok> |
| Component: | mc | Assignee: | Radek Vokál <rvokal> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | cristian.ciupitu, dgunchev, dvlasenk, groknok, mrmazda, next.little.owl, pahan, rvokal, slavazanko, van.zantvoort |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-06-29 11:46:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Piscium
2013-02-18 22:17:50 UTC
With my 64 bit 3.0GHz family 15 model 4 stepping 3 F18/KDE host gx62b, MC starts instantly whether on the ttys or in Konsole. I understand now better what happened. It started with Anaconda for F18. As I could not find a way to set the host name, I changed it after installation by modifying the file /etc/hostname. This is what made MC start slower. The way to fix the problem is then to revert /etc/hostname to its default value (“localhost”), however I do not like that. I found another solution, adding the new host name to /etc/hosts. I tested two ways that both work: adding the new host name as an alias for localhost, or alternatively adding a new line in the file with a different address (such as 127.0.1.1). The question is then: is this a MC bug or not? I don't know. I also noticed that when MC is slow to start, the command dnsdomainname also is slow. Maybe there is a common cause, and it might be the function gethostbyname in glibc (or a function called by it, or systemd). In a nutshell, I solved my immediate problem (MC not working) but there may be a bug, and I don't know enough to say there is (or isn't). Hopefully someone more knowledgeable will be able to shed some light on this. I don't mind if this issue is closed. > #9 0x000000336830b2dd in gethostbyname (name=name@entry=0x92c770 "tornado") at ../nss/getXXbyYY.c:116
Check your /etc/hosts file or DNS settings. Your computer should know how to resolve own hostname to IP address and vise versa. Also, please check resolving for 'localhost.locakdomain' hostname.
This is my current /etc/hosts: ============= 127.0.0.1 localhost.localdomain localhost ::1 localhost.localdomain localhost6 localhost 127.0.1.1 tornado ============= The first two lines are the default on my Fedora 18 box (except that I added some extra whitespace). I manually added the third line and that solved the problem (however as I said in my previous comment, adding "tornado" to the first line is an alternative way to solve the problem). The question now is this: is there a bug or not? if yes where? in MC? in some other tool? If you do "man hostnamectl" you will see that it does not mention /etc/hosts. Is there a bug in hostnamectl? See also Bug 856456 and Bug 890027. > The question now is this: is there a bug or not? It's a good question. Same behavior will be for Sendmail, for example. > if yes where? in MC? Yes, in MC. In Smbfs module, if more exactly. The module is deprecated (because have a lot of code from very old Samba implementation). The module will be rewritten for usage of the libsmbclient library in near time (hope, month or two). But I don't sure that new module will not add a delay when host will have issues with the DNS names lookup (it will be tested of course, but not now). > Is there a bug in hostnamectl? Generally it's a bug with the DNS names lookup. The bug may be in your /etc/hosts, in the dnsmasq package, in /etc/nssswitch.conf or in /etc/resolv.conf files. It happens when computer haven't had ability to transform own hostname to an IP address and/or vise versa. He-he, I remember this behaviour from the previous century, so it's a century old bug :D No, seriously, I use that 'bug' to check if I missed to edit /etc/hosts after changing the host name. You'll notice similar problems in other programs too, but mc is my litmus paper for that. This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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. I seem to have the same problem with mc-4.8.11-1.fc20.x86_64. It took forever to start when the DNS servers weren't responding (the host host command returned ";; connection timed out; no servers could be reached"). Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. The reason is the way how the virtual smbfs is initialised. The call chain is: main() [src/main.c] vfs_plugins_init() [src/vfs/plugins_init.c] init_smbfs() [src/vfs/smbfs/smbfs.c] vfs_register_class() [lib/vfs/vfs.c] smbfs_init() [src/vfs/smbfs/smbfs.c] get_myname() [src/vfs/smbfs/helpers/lib/util.c] Get_Hostbyname() [src/vfs/smbfs/helpers/lib/util.c] sys_gethostbyname() [src/vfs/smbfs/helpers/lib/system.c] ... ... <the main loop of mc> The problem starts in get_myname() and continues to sys_gethostbyname(). The code can generate several unsuccessful calls of gethostbyname() with timeouts and it can block the initialization of the main loop for very long time. This is a fundamental design issue, no slow network related operations, like a DNS lookup, should be allowed to block the main execution loop and UI. Given the current state of code of the virtual smbfs, which is fortunately deprecated, I suggest to build mc without support for smbfs, at least until it is possible to disable this functionality in Options->Virtual FS menu. It means to remove "--enable-vfs-smb" from the SPEC file. http://www.midnight-commander.org/ticket/40 appears to be the upstream bug covering this. This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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. Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |