Talk:Network Time Protocol daemon

From ArchWiki
Revision as of 17:54, 22 February 2014 by Lahwaacz (Talk | contribs) (New structure?)

Jump to: navigation, search

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)
I should have explained my proposed structure more succintly like you've done, I'll remedy now:
Usage
    As a daemon
        Check correct synchronization
        Running in a chroot
    Without daemon
Autostarting
    systemd
        Daemon
        Synchronize once per boot
    Netctl
    Wicd
    NetworkManager
In my view this structure allows avoiding any duplication of information, because the difference between the daemon/no-daemon uses can be all explained generically in the Usage section (answering Lahwaacz's post above), and then just appropriately linked from the examples in the Autostarting subsections. This also should answer Idomeneo1's request for neutrality in connection manager cases (yes, I've put the daemon section first as I agree it's the one to be considered most basic). For example the Wicd section could be:
Executing ntpd once after successful connection of Wicd can be achieved by creating a script in the appropriate postconnect directory. The following example uses ntpd #without a daemon:
example
"Running in a chroot" could be moved to the bottom of the article for slimming "Usage" down, however IMO it is a particular "usage" of ntpd.
The "Usage" section aims to explain how to use the ntpd command, nothing less nothing more. Since all the methods in the subsections of "Autostarting" end up using the ntpd command through non-ntp-specific applications, they're not part of the "usage" of ntpd, and they don't belong under "Usage". In other words, "Autostarting"'s goal is to explain how to have the ntpd command launched automatically after some particular events; theoretically it could also link to Autostarting.
-- Kynikos (talk) 15:55, 21 February 2014 (UTC)
Well, I just don't like putting solutions using different methods into the same section, but with proper linking... why not?
Note that implementing the three remaining solutions is rather trivial, you just replace ntpd -q with systemctl start ntpd etc. But then there is the caveat "ntpd should still be running when the network is down if the hwclock daemon is disabled, so you should not use this" in Network Time Protocol daemon#NetworkManager. I guess it just confirms that the word "hook" has an implied meaning: "hack"...
My compromise proposal would be to merge "systemd" section in the Kynikos' example into "Usage" and rename "Autostarting" to "Tips and tricks" (<rant>or just "Hacks"...</rant>).
-- Lahwaacz (talk) 17:59, 21 February 2014 (UTC)
@Kynikos - Ach OK, now I see - a usage section would obviously cover the command line, so it doesn't need any subheadings of its own. The structure is fine.
In the network managers, the one-shot flags should be removed from the default instructions, and leave it up to the users if they want to run it one-shot for some reason.
Do the server instructions need to come before the client instructions (which most people will consult the Wiki for)?
A lot more updating needs to be done, too.
@Lahwaacz
"ntpd should still be running when the network is down if the hwclock daemon is disabled, so you should not use this"
Have you disabled your "hwclock daemon"? Is this factual, current information, or are you just trying to make points quoting from a problematic article.
Idomeneo1 (talk) 19:38, 21 February 2014 (UTC)
He is not trying to make points, but explaining why he wants to rename the "Autostarting". Good you find yourself in Kynikos' structure, Idomeneo1. Adding your both suggestions, and another, one might come up with something like:
Installation 
        (stays same:) 
Configuration 
    Configuring_connection_to_NTP_servers 
        (stays same) 
    Configuring_your_own_NTP_server 
        (stays same) 
    Running in a chroot 
        (May be moved here because it is a matter of configuring how the daemon is -or should be- run) 
Usage
    Without daemon 
        (or "Console" or "Manually"; I would move the cli first, simply because it introduces options, be it "-q" or "hwclock" or ...)  
      Check correct synchronization 
        (this is explaining a cli option as it is written currently, even though it needs a "systemctl start ntpd" first to make sense)  
    systemd  
        (as per proposal by Lahwaacz; just changing header. Hint: For systems with frequent a one-shot may be enough; JstJohn's argument from the other talk)  
      Daemon
      Non-Daemon 
        (="Synchronize once per boot") 
Autostarting 
        (or "tips & tricks", "Networking autostart hacks" or "Autostarting with network". Note at the top about "-q or not" as per Idomeneo1's suggestion)
    Netctl
    Wicd
    NetworkManager
See also 
        (stays same)
--Indigo (talk) 20:37, 21 February 2014 (UTC)
Indigo, have you disabled your "hwclock daemon"?
Idomeneo1 (talk) 21:55, 21 February 2014 (UTC)
Yes, it's funny. But you mix #hwclock daemon and #New structure?. You have further comments to the structure? --Indigo (talk) 00:05, 22 February 2014 (UTC)
Yes, funny indeed! So it certainly wouldn't be me who's throwing hwclock daemons into a discussion on restructuring the ntpd article.
Idomeneo1 (talk) 03:04, 22 February 2014 (UTC)
Is it possible to stay on topic please? Thank you, this branch of the discussion is closed. -- Kynikos (talk) 03:22, 22 February 2014 (UTC)
I really wish you had responded to Lahwaacz's red herring in this way, instead of to my response to someone apparently taking the red herring seriously.
Idomeneo1 (talk) 16:27, 22 February 2014 (UTC)
Commenting Indigo's proposal:
+1 for moving "Running in a chroot" under "Configuration".
Honestly I still don't like "systemd" under "Usage" because:
  • enabling the systemd service is not compatible with the connection manager methods (i.e. it's alternative to them and vice versa)
  • the systemd service ends up launching the ntpd command itself, so, despite being part of the ntp package, it's still an "accessory" and not a "core" usage feature of the ntpd command
To me "Without daemon" and "Console" or "Manually" are not synonyms, in fact ntpd forks by default (except with the -n flag) and runs "without daemon" only with the -q flag; for example ntpd.service launches it with "-g -u ntp:ntp -p /run/ntpd.pid". Of course all this is true unless we have different definitions of "daemon" and "without daemon".
We may even consider generalizing the Wicd and netctl sections like it's already been done to NetworkManager, which simply links to NetworkManager#Network_services_with_NetworkManager_dispatcher, i.e. Wicd may link to Wicd#Scripts for details, and in netctl we may add a section mentioning ExecUpPost and ExecDownPre and then link there too. Probably all these sections should better be also mentioned from Autostarting.
-- Kynikos (talk) 03:22, 22 February 2014 (UTC)
I'm convinced, thanks. One further comment to your original structure above: If we move systemd into "Autostarting" (or "Starting the daemon"), we might in fact find the "Usage" does not need subsections at all. It could just explain (as you do above) how (a) "ntpd" starts without options, (b) mention "-q" along with hwclock, then maybe (c) other options used in the "Autostarting" examples, and (d) end with mentioning ntpq invocation (maybe even as a tip only). Maybe the "Usage" section in itself like this would _not_ be too long anyway (so that it requires subsections), but that would show along the lines. edit: added "_not_" --Indigo (talk) 10:41, 22 February 2014 (UTC)
If we're going to link the network managers, we do need to look at what we're linking to, and make sure it's clear and helpful.
Suggest adding sub-headings "At boot" and "At network connection" under "Autostarting", for quick reader orientation.
Idomeneo1 (talk) 16:27, 22 February 2014 (UTC)
@Indigo: actually, I meant to merge (not move) the "systemd" section into "Usage", meaning that the section headings would not be preserved and the daemon/non-daemon distinction would be done only once:
Installation
    (stays same)
Configuration
    Configuring_connection_to_NTP_servers
        (stays same)
    Configuring_your_own_NTP_server
        (stays same)
    Running in a chroot
        (May be moved here because it is a matter of configuring how the daemon is -or should be- run)
Usage
    As a daemon
        (describe both "ntpd" and "systemctl start ntpd" startup methods, advantages over "Without daemon")
      Check correct synchronization
          (this '''needs''' the daemon running, so please don't put it under "Without daemon")
    Without daemon 
        (describe the "-q" flag, advantages over "As a daemon", custom service file for systemd startup)
Networking autostart hacks
    Netctl
    NetworkManager
    Wicd
Just one more comment on the post that followed:
- "enabling the systemd service is not compatible with the connection manager methods" - @Kynikos: it should be enough to put something like "disable the ntpd service" (or maybe elaborate further) at the beginning of the "Autostarting"/"Networking autostart hacks". In fact, networkmanager-dispatcher-ntpd is using the systemctl start/stop ntpd.service command(s), so the user should be aware of how ntpd.service works - especially when implementing similar solutions for netctl/wicd.
My suggestion obviously contradicts with your definition of what to put into "Usage". I just wanted to clarify my suggestion (sorry for not being specific right away); if it is declined, I'll accept your definition.
-- Lahwaacz (talk) 17:53, 22 February 2014 (UTC)