Talk:Network Time Protocol 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
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)
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.
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 , 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 -qwill 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
-gflag. 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)
- I think you are proposing the following scheme (let's call it A):
- - "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:
- "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
systemctl start ntpdetc. 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.
- "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)
- 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)
- @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
ntpdservice" (or maybe elaborate further) at the beginning of the "Autostarting"/"Networking autostart hacks". In fact, is using the
systemctl start/stop ntpd.servicecommand(s), so the user should be aware of how
ntpd.serviceworks - 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)
- Trying to find a compromise to all the observations made since my last post ("Installation" and "Configuration" are agreed upon so I'll omit them):
Usage As a daemon (describe both "ntpd" and "systemctl start ntpd" startup methods (but not "enable"), advantages over "Without daemon") Check correct synchronization Without daemon (describe the "-q" flag, advantages over "As a daemon", custom service file for systemd startup) Autostarting At boot (systemd) (mention "systemctl enable ntpd" and describe "Synchronize once per boot" here) At network connection Netctl NetworkManager Wicd
- @Indigo: I think subsections of Usage will be handy as targets for links from other sections.
- @Idomeneo1: ok for distinguishing "At boot" and "At network connection"
- @Lahwaacz: you're right, we can talk about the service in "As a daemon", but still the reminder to enable it should better be put under Autostarting ("At boot (systemd)") for clearer comparison with the other autostarting methods. Well done looking into how works, it will be useful to mention that in the article.
- I've also restored "Synchronize once per boot" under "At boot (systemd)".
- -- Kynikos (talk) 06:18, 23 February 2014 (UTC)
- As I understand it, both
ntp-once.service(currently in Network_Time_Protocol_daemon#Synchronize_once_per_boot) would be described under "Usage", but the instructions to enable them would be given under "Autostarting"? -- Lahwaacz (talk) 07:32, 23 February 2014 (UTC)
- As I understand it, both
ntp-once.serviceserve as an Usage example might be ok but, as your question already implies, creates problems without duplication. Plus your point about the NM-dispatcher gives another reason that having a mention of the two services would be superfluous in Usage for some readers, because what they need depends on "Autostarting" method chosen. I'm +1 to moving all service files into "Autostarting" and just explain ntpd invocation (a,b,c,d) and the advantages in the Usage daemon/Without subsections and link down. --Indigo (talk) 10:53, 23 February 2014 (UTC)
- There's only one little detail that doesn't convince me yet (but could be ignored at this stage): while in 99% of cases the systemd service will indeed be used to "autostart" ntpd, it's not strictly an "autostarting" method, as only the "enable" part is, while the "start" action is not "auto", but "manual" :) This is what made me change my mind in my previous post.
- Anyway we can start the restructuring following the plan to reserve the "Usage" section only for the ntpd command, and see how it goes. Maybe it will need a slightly different substructure from the one in the last draft, depending on how we implement the a,b,c,d points and the advantages/disadvantages.
- -- Kynikos (talk) 14:39, 24 February 2014 (UTC)
- This line should be removed, because systemd does the job, and hwclock daemon is not currently part of Arch.
- Idomeneo1 (talk) 14:39, 25 February 2014 (UTC)