I've emerged the net-misc/ntp-4.1.2 package and I run the ntp-client script at bootup to sync time to atomic clock. This worked great until I emerged net-dns/djbdns-1.05-r8/9 so I could use dnscache to get a little faster DNS responses. The problem is that the dependencies or nature of the ntp-client bootup script and svscan script is such that dnscache hasn't been started when the ntp-client script runs. In my /etc/resolv.conf, I have the line "nameserver 127.0.0.1" When ntp-client starts, it can't resolve the name of the time server I use. I know that svscan is the very last service that starts on my bootup. I checked the scripts and see that ntp-client depends on dns, but svscan doesn't provide it, because not everyone will run dnscache with svscan. So, for now, I made svscan provide dns and wait a few seconds after it starts (daemontools has a delay like that), and it works. You might have to change it to something like this in portage, but it's not elegant because of the delay daemontools does and because svscan doesn't always provide dns. I suggest we scrap daemontools, use daemontools instead of init (or list it in inittab), or make it so svscan is one of the first scripts to start. Maybe we just leave it so that in a special case like this, the user has to modify scripts, but that's not very nice either... I see that svscan is supposed to run before ntp, but I'm not sure why. Maybe it should also run after ntp-client? I realize there are a few other reports related to daemontools/svscan but I don't think they address this issue -- generically, there needs to be a way to specify that svscan is dynamic and won't always provide the same services. Reproducible: Didn't try Steps to Reproduce: 1. emerge ntp 2. [configure ntp client with the name of a time server, /etc/conf.d/ntp-client, NTPCLIENT_OPTS="-b <server_name>"] 3. rc-update add ntp-client default 4. emerge djbdns 5. [set up dnscache, change resolv.conf to point to lo interface] 6. rc-update add svscan default 7. boot and ntp-client can't resolve time server's name. After complete boot, manually running the script should work. Actual Results: Expected Results:
*** This bug has been marked as a duplicate of 46642 ***
