Christopher Metter put forth on 10/31/2010 11:46 AM:

Hi again,

sorry for late response, but I was busy doing other things.

Thanks Stan, your tip fingering ntp to be the culprit was right!

Was ntpd really the problem or were you missing a loopback interface? What is the output of 'cat /etc/network/interfaces'? Do you see:

auto lo iface lo inet loopback

or something similar?

After reading different FAQs on ntp and reconfiguring /etc/ntpd.conf, I just purged ntp AND ntpdate (Don't ask me why both were installed), rebootet and everything was fine. After just installing ntp and another reboot everything still was okay and now I dont have any ntpserver starting ;) I assume the installation of both ntp and ntpdate was the problem.

ntpd and ntpdate serve two different functions, well, actually the same function but in two different ways. Most Linux distros have both installed automatically. Removing ntpdate won't fix a config problem with ntpd. ntpdate is an interactive (command line) utility. It can be setup to run via cron once or twice a day to sync the time to an ntp server instead of using ntpd. Best practices calls for ntpd however, and recommends against using cron'd ntpdate. The latter puts too much stress on the world's ntp servers when everyone does it that way, since most OPs that did so scheduled syncs at noon and midnight. So the ntp servers would get flooded with millions of requests in a period of a few seconds, twice a day--not good.

You really, really need accurate time on a mail server, which means you should have ntpd configured properly and running. On most Linux distros today all you have to do is install the package and the install script takes care of the rest. You may need to configure your pool servers manually. For you those should probably be:

0.de.pool.ntp.org 1.de.pool.ntp.org

Just for fun, what is the complete output of (executed on the mail server shell of course):

ntpdate -q 0.de.pool.ntp.org

This will make a query without changing the local machine time. It will tell us the current error of your clock.

Thank you for your help.

You are very welcome. Now let's make sure we get your system time sync running properly. :)

-- Stan

Greetings, Christopher Metter

Am 24.10.2010 05:27, schrieb Stan Hoeppner:

...

Christopher Metter put forth on 10/23/2010 4:02 PM:

...

Hi there!

Im using a dovecot system in combination with postfix(with dovecot lda) and ldap. Till today it ran well, but before switching to live, i did some system updates and at the reboot following message occured:

Starting IMAP/POP3 mail server: dovecoUnexpected first line<localhost: timed out, nothing received> This is an NTP error--has nothing to do with Dovecot. Apparently you're missing a loopback interface (127.0.0.1) or you have a goofy iptables setup breaking access to the LBI. If simply the former, create a loopback interface and reboot. Problem should be solved. If the latter, find the iptables rule causing the problem and eject it.

...

(First it says: "Starting IMAP/POP3 mail server: dovecot ", but then something fails and overrides the "t" of dovecot with "Unexpected.... ") Stuff is constantly overwritten on the physical console on Linux boxen these days. This is "normal", although unsettling. Parallel daemon startup is now the default on most (all?) distros today. This allows faster startup, but it also causes errors to be reported "out of order". In your case, ntpd was started but it took a few seconds to timeout. By that time many other daemons had started up. It just happens that ntpd timed out right when Dovecot was loading, so it "appears" the error is Dovecot related, when in fact, it is not.

You can eliminate this problem by disabling parallel startup. This will fix the "out of order error reporting" but your machine will start up much more slowly, especially if have any daemons that always time out. ;) I highly recommend you _not_ disable it.

Oh, and btw, fix your ntp configuration to act as a client only, not both a client and server, and configure an external time source. Mail servers, above all others but maybe DB servers, need the clock to be accurate.

Christopher Metter put forth on 10/31/2010 1:51 PM:

To sum it up: Config with packet ntp installed runs properly and I still think that ntpdate throws the errors. Even system Startup is faster without it. Its 60seconds vs ~18seconds on rc2.d startuptime.

ntpdate is a mostly, to me, a command line utility. It is not a daemon. If installing the package "ntpdate" is causing problems at boot, it is very likely that your Linux distribution has an ntpdate install script that is sticking an ntpdate command in rc.local or some other place that causes it to run at boot. When this occurs, it's probably tying up the socket when ntpd tries to grab it. Install ntpdate again, and afterward, check rc.local and the rc*.d directories for a script that is running ntpdate at startup. Remove the reference to the script or command once you locate it.

ntpdate is useful for a sysadmin to do a manual check or set of the local clock against a specified ntp time source (possibly different from those configured for use by ntpd). It should not interfere with ntpd, at least not when using the query only switch. Debian Linux, for example, in my experience, doesn't have this problem you are experiencing while both ntpd and ntpdate are installed. I've never had a problem with it.

If I aint wrong, my system time is still accurate. And the problem is solved, or did I miss something?

If you never need to use ntpdate then I guess you could say your problem is solved. For me, personally, I use ntpdate specifically as a sanity check on occasion against ntpd to make sure what the latter is doing or reporting is accurate. ntpq -p doesn't necessarily guarantee that.

If you never have used ntpdate from the prompt in the past, and never intend to, then I guess you're good to go. Carry on. ;)

-- Stan