Change:
ttf_bitstream_vera = callPackage ../data/fonts/ttf-bitstream-vera { }; <ins> ubuntu_font_family = callPackage ../data/fonts/ubuntu-font-family { }; </ins> ucsFonts = callPackage ../data/fonts/ucs-fonts { }; unifont = callPackage ../data/fonts/unifont { };

Discussion:
I was trying to look into this more, but one of the most recent updates (builds since ) broke my hostname lookup. $ wl $ hostname: Unknown host $ hostname: Unknown host
Could you post the output with the -v flag? Here all the commands you mentioned work.
[]# hostname -v gethostname()='
And something with the latest repository and an error and verbosity?
nixpkgs: [root hostname -va gethostname()=' Resolving`' ... hostname: Unknown host From what I could determine it looks like something to do with nss-myhostname is broken.
After a recent upgrade (possibly after switching to NixOS 15.09, not sure) I have this problem again. I have this in I noticed it because emacs takes a long time to startup. This occurs to me inside a virtualbox machine.
This is the content of
You can work around this by adding . But this should be a trivial fix in Replacing with should do the trick. Adding an equivalent to the IPv6 config would also make sense.
I did it: But don't think it is the right solution. This way works but it is slow:
Oh wow, mine resolves much faster:
Can you do those commands under , e.g.: and paste it here? Normally (without ) should just call and do no DNS lookups. Also show your and .
And make sure is running. Without it, probably (which is responsible for making sure the hostname resolves to an IP address) won't be found.
But even without , should fall back onto . I am actually not running , so I just tried . It finds my hostname through /etc/hosts without any issues, it particularly does not take 15+ seconds. It does, however, try to DNS resolve before going to , so a slow DNS resolution may be the issue here. A simple ends up looking at without ever accessing the outside world. I don't think there is really anything wrong here. I do find it curious that seeks out my DNS server before going to , I had expected it to be the other way around.
According to systemd nscd is OK:
The output of is an empty string. Here is its strace:
Perhaps I had to mention it before explicitly: the machine has no DNS registration (it is a virtual box guest).

(But neither had it before and emacs had no slowdowns at startup.) (without ) works here too, both with and without to :
Still no and . Also, looking at the traces, can you show the output of ?
Ah, sorry!
All of these look normal to me, does exactly the same thing when run on my machine. Except it timeouts on DNS requests ("Timeout" in s in the trace). With the information you've shown till now I would guess that the problem is outside of NixOS. If you think that the problem is with NixOS then: Can you run the problematic command under or describe what is the problem with the traces you've shown here? (If the program forks under ( doesn't), you can do , e.g. to trace its children. I absolutely wouldn't want to read that, unless it's a last resort.) Is your primary problem a problem? Are you sure that your problem is problem? Why? Please document any changes you do to or paste contents of all the generated , and files along with the traces. E.g. it's unclear whenever is a trace with which . Don't "snip" pieces from the traces and other outputs of commands. If possible, boot the system with the older generation from boot menu (the one that worked) and post the traces from there. Meanwhile, with "not a NixOS problem" hypothesis in mind I would 1) try to run the problematic command with set to both possible values in and compare the traces (possibly in both generations, if you don't have the the previous generation's config you can hack around this by disabling and then ing it's socket so that systemd wouldn't socket-activate it) to be sure; 2) check , , and on both vm and host; 3) fire up on vm and on host and then try the problematic commands (in both generations); 4) try a different DNS server in vm; 5) try a different virtualized network driver (if possible); 6) try a different virtualization system.
thank you for your suggestions and your time. So, l'll try to recap the situation: My principal problem is that emacs is slow at startup. (An strace of emacs is at the bottom of this message.)

I believe that the problem is in NixOS because: It has been a while since I did any update on the host system (a MacBook Pro running Yosemite); The computer is connected to an ADSL wifi at home where everything is unchanged and seems OK; I installed a debian guest, and I don't have the same problem on that. I'll try to provide more information. First of all, here is a recap of my configuration. (I also tried adding but it doesn't help.) Here is the configuration on the debian host that works: Here is the command I use to test emacs. Recall: is "do not load init files"; is "run lisp function"; is "exit emacs". (On the debian guest this takes a fraction of second.) Finally here you can get the strace of the emacs execution. The three "Timeout" near the end are those that slowdown the startup.
Does it change anything when you add to /etc/hosts?
Do you happen to use DHCP in the Debian guest, but not in the NixOS guest? Is '192.168.1.1' your ADSL router? If the answer is "no" fill the other IP address, if "yes":  Does from your vm gets its pongs?  Does from vm (install package) return a correct filled "A" record?  Does from vm return a correct "A" filled record?  Does from vm return a correct "A" filled record? What's the output of in vm? Does your router run Linux? If the answer is "yes":  What's the output of or on the router?  Does it run daemon?  What's the config of that? Does any or both of the following together fix your problem?  Does removing the line from that file in the vm help? and then to revert.)  Does changing the line in help? (The same method applies.)
Just wanted to remark that I had the same symptom (slow Emacs startup), and before I even looked to see if anyone had reported a similar issue, I straced Emacs, saw references to my system's hostname, immediately checked , and grumbled upon finding that it had no entry for it--just and .

So I to : it solved the problem, just as it has 99% of the time in the past thirty years I've come across a sluggishly-misbehaving Unix machine that was missing an entry for itself in . :) This really ought to be the default, with an option to disable it if desired.
tl;dr: if you want to avoid an outgoing AAAA DNS query for yourhostnamehere when happens, then add a line in /etc/hosts like . Hi. I didn't read this whole thread but, if an ipv6 entry for the host is missing(even though ipv6 is disabled in 2 ways - see below), then an outgoing DNS query is issued regardless. eg. 1. (term1) sudo tcpdump -vvvvv dst port 53 2. (term2) sudo systemctl restart nscd && hostname -va (term2) (term1) with : and with containing and having . (as confirmed by ) 3. (term2) Can also replace with or to get the same outgoing dns query: It gets the right hostname but at the price of an outgoing dns query: Unplugging cable (even though we're in virtualbox), will still make this work, just rerun step 1 and 3 above. <s</sEDIT2: grrr I had to edit some wrong pastes! (I kept forgetting to right click and copy, else it would paste the previously copied text!) <s</sThe permanent fix to avoid the outgoing AAAA dns query for your hostname, is to add this line in : so now I have: Now remember, I still have ipv6 disabled in those 2 places though! But no outgoing AAAA query this time! (note, had to rerun step 1 and 3) Btw, now resolved to nothing: Hmm, I guess I should add an alias maybe... let's say. or just replace with ... So, why was this bad? at some point in Gentoo or/and Manjaro, running and for the first time, while network cable was unplugged, would hang and I found out it's because they both were running , however in nixos they don't seem to do that! (but I only tested aka midnight commander) EDIT: tested on nixos-unstable channel
what happens when you add to the file?

Will that prevent the lookup?
Ah, very good point ! I don't know how I missed talking about that. The answer is no, however. The lookup still happens, if I comment out (but kept the line which comes with a msvp hosts file which I downloaded because I currently couldn't edit it out due to file being symlinked) Tested on with both and variants separately. To fix(no outgoing query) just uncomment the second line(although I uncomment both) here:
It's worth noting that, if isn't running, then having only these in : Will cause both an and an outgoing queries. But I figured, the wasn't happening due to taking care of that part! (while it is running) Now, start that baby up and what do you know?! Now, I guess since the is taken care of by , then maybe it should(?) also take care of the ? or we should not forget to add to /etc/hosts in this case. Cheers! EDIT: Note that the queries are made by tcpdump, to avoid those just add the arg. ie. EDIT2: is what I'm using as a workaround, although, I'm not sure if something similar should be instead.
Debian GNU/Linux 7 pro/contra of resolving the own hostname to the first network interfaces ip instead of 127.0.0.1? how would one get the first interfaces ip on systemd systems? the workaround also fixes for me: but puts the hostname before the domain: on the debian maschine: it's still the case with debian style hosts:
Let me add my 2 cents. Let's get back to . Some mentioned Debian does it, it seems nobody mentioned why. Apparently, some apps expect that mapping canonical hostnames to an IP, and mapping that IP to an hostname, returns the same hostname. [Some argue those apps are broken, yet Debian still does it.] More apps expect that 127.0.0.1 and localhost map to each other. To have both conditions, you can't map the hostname to 127.0.0.1—but 127.0.1.1 avoids the problem. And it's still a loopback IP! Is that IP constant? If yes, you're good.

IIUC that was the standard configuration, back when Unix systems all just had static public IPs. Quoting from the on this: See also , where this was decided. EDIT: here's another reference for this behavior:
myhostname was broken at some point (nss module was not in library path of nscd), but it works again and returns an ip for the hostname: