Talk:Network Time Protocol daemon

From ArchWiki
Revision as of 00:16, 21 February 2014 by Jstjohn (Talk | contribs) (New structure?: fix indentation level of Idomeneo1's reply)

Jump to: navigation, search

Creation history

This article has been created after splitting "Network Time Protocol" into this and OpenNTPD as discussed here -- Kynikos 16:03, 11 February 2011 (EST)

hwclock daemon

According to this post in the forum, the hwclock daemon is not necessary anymore thanks to systemd, so I'm willing to update this page unless someone have a objection. Tae (talk) 20:53, 28 December 2012 (UTC)

I'm removing the the hwclock daemon warning. The forum post linked above, Daemons_List, and pgrep hwclock or ls /usr/lib/systemd/system/ on my own system indicate that there is no reason to disable a hwclock daemon. ChariotOfFire (talk) 10:37, 19 March 2013 (UTC)

Canonical usage

I find this article quite confusing. My use case is simply that I want to make sure my machine time is sync'd. I'd suggest that at (or near) the top of the article (before the section on setting up a server) you have info on the canonical approach for this. The part where this is at the moment is quite bad.

What's the canonical approach daemon or no daemon?

Once selected, what's all the warnings about hwclock. Again, canonical. If hwclock needs to be turned off, just state that, not in RED! Hope those comments help the article??? Also there are references to rc.conf...shouldn't this be deprecated? Up front, on top, the systemd approach probably.

-- Ftravers (talk) 13:50, 14 February 2013

New structure?

In ArchWiki talk:Reports#User:Idomeneo1, User:Idomeneo1 has requested a structure that deals with autostarting methods regardless of the daemon or oneshot usage of ntpd. In User:Kynikos/ntpd I've drafted a possible structure that I don't necessarily support, but that will be useful to give some tangible material for a more constructive discussion. Share here your opinions and possibly alternative proposals, or arguments in support of the current structure. -- Kynikos (talk) 13:33, 20 February 2014 (UTC)

The command line start doesn't have a logical heading of its own, and consists instead of two subheadings, smushed with "Running in a chroot".
An intuitive structure would be something like "Autostart at boot" "Autostart at network connection" "Command line start"
Following jstjohn's post, it seems that the daemon should be given pride of place (with a note about the current bug).
Also Ftravers makes a good point about moving all this "Usage" business to the top of the article, as something like "Setup".
Idomeneo1 (talk) 14:20, 20 February 2014 (UTC)
I think you are proposing the following scheme (let's call it A):
Autostart at boot
    As a daemon
    Without daemon
Autostart at network connection
    Netctl
    NetworkManager
    Wicd
Command line start
    As a daemon
    Without daemon
instead of the following scheme, which (more or less) reflects the current scheme (let's call it B):
Using without daemon
    Command line start
    Autostart at boot
    Netctl
    Wicd
Running as a daemon
    Command line start
    Autostart at boot
    NetworkManager
There are some minor issues with A, some current sections do not fit into this scheme or would have to be duplicated, but let's pass over it. The biggest problem is that A does not reflect the fundamental difference between "Running as daemon" and "Running as ntpd -q" (more info below) in the "Autostart at network connection"; and the description for this difference would have to be duplicated for the other sections. On the other hand, B does not have this problem "by design". Moreover, titles "Using without daemon/Command line start" and "Running as a daemon/Command line start" do not have duplicate content, the instructions in these sections are very different.
I must disagree with [1], in my opinion there is a fundamental difference between "Running as daemon" and "Running as ntpd -q". Programmatically the difference is obvious, but it matters greatly even for users. Running as a daemon allows to synchronize the time much more frequently (according to Time the period is 11 minutes), allows to decrease the system clock drift (see Time#Time_skew), and possibly more that did not come to mind at the moment. By design, running ntpd -q will cause ntpd to set the time once and immediately exit. This has the consequence that the time is synchronized only when the system is started, or a network connection (re)established. In the end, the time will be synchronized only a few times per day/week, depending on how often the users reboot/loose network connection. Note that you need more than one synchronization cycle to actually get a "precise" time, even when using the -g flag. Unless the users have a very precise hardware clock, the system clock drift might be too big for some applications.
I think that Time is a prerequisite for this page, but it is linked only from the "See also" section. This page might indeed need some expansion, but I don't think that the example A is the right way.
-- Lahwaacz (talk) 17:50, 20 February 2014 (UTC)
- "fundamental difference between "Running as daemon" and "Running as ntpd -q""
The fundamental difference, as you give it, is the explanation why the daemon should be preferred over the one-shot, not why we should subordinate the applications to 2 variations of ntpd, one of which, as you point out, is the recommended default, and the other a flagged once-through.
- "B does not have this problem "by design""
You would have to duplicate everything in B! All these apps can run ntpd as daemon or as one-shot, presumably NetworkManager too. Yet you assigned them, apprarently arbitrarily, to daemon or one-shot.
- "Time ... is linked only from the "See also" section"
Time is linked in the very first sentence, in totally normal Wiki fashion. I am not opposed to linking it more often, but that was another inaccurate representation of what is going on with this page.
Idomeneo1 (talk) 00:12, 21 February 2014 (UTC)