| Summary: | ntpdate always fails | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Chris Denice <eatdirt> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | bittwister2, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | ntp-4.2.6p5-31.mga6.src.rpm | CVE: | |
| Status comment: | |||
(In reply to Chris Denice from comment #0) > Description of problem: > > There is a service named "ntpdate.service", which fails all the time as > reported by systemctl. Not on my install. $ systemctl status ntpdate.service ntpdate.service - Set time via NTP Loaded: loaded (/usr/lib/systemd/system/ntpdate.service; static; vendor prese Active: active (exited) since Wed 2016-08-31 16:47:42 CDT; 17h ago Main PID: 1437 (code=exited, status=0/SUCCESS) CGroup: /system.slice/ntpdate.service I have yet to see it fail during boot. # cat /etc/release Mageia release 6 (Cauldron) for x86_64 This is on a clean network install on two systems. CC:
(none) =>
bittwister2 Arg! I have this issue on 2 differents mga6 machines. That's weird. Under drakclock, I get a message claiming no servers found for sync, while pool.ntp.org seems to work fine drakclock has some issues in configuring things correctly, so that may be your issue. The ntpdate service uses what's in /etc/ntp/step-tickers, so make sure you have an appropriate NTP server listed there. I imagine this bug is INVALID. Hi there, I would like the bug to be invalid: cat /etc/ntp/step-tickers pool.ntp.org ping pool.ntp.org PING pool.ntp.org (85.88.55.5) 56(84) bytes of data. 64 bytes from ntp.rack66.net (85.88.55.5): icmp_seq=1 ttl=59 time=1.99 ms 64 bytes from ntp.rack66.net (85.88.55.5): icmp_seq=2 ttl=59 time=1.78 ms but I don't find why it does not work on my 2 cauldron machines :-/ I have also "network.service" failing although both of my network interfaces are up and connected. Maybe this could be related!? thanks for the help! (In reply to Chris Denice from comment #4) > Hi there, > I would like the bug to be invalid: > > cat /etc/ntp/step-tickers > pool.ntp.org > > ping pool.ntp.org > PING pool.ntp.org (85.88.55.5) 56(84) bytes of data. > 64 bytes from ntp.rack66.net (85.88.55.5): icmp_seq=1 ttl=59 time=1.99 ms > 64 bytes from ntp.rack66.net (85.88.55.5): icmp_seq=2 ttl=59 time=1.78 ms > > but I don't find why it does not work on my 2 cauldron machines :-/ Maybe because using chrony is expected? [root@localhost Desktop]# systemctl -a | grep ntp â ntpd.service not-found inactive dead ntpd.service â ntpdate.service not-found inactive dead ntpdate.service â sntp.service not-found inactive dead sntp.service [root@localhost Desktop]# systemctl -a | grep chrony chronyd.service loaded active running NTP client/server [root@localhost Desktop]# [marja@localhost ~]$ cat /etc/ntp/step-tickers cat: /etc/ntp/step-tickers: No such file or directory [marja@localhost ~]$ cat /etc/chrony.conf | grep server # Use public servers from the pool.ntp.org project. server 0.nl.pool.ntp.org iburst server 1.nl.pool.ntp.org iburst server 2.nl.pool.ntp.org iburst #server 1.nl.pool.ntp.org #server 2.nl.pool.ntp.org # Serve time even if not synchronized to any NTP server. [marja@localhost ~]$ CC:
(none) =>
marja11 Well, you either use chrony or ntpd, I don't think that's the issue. I suppose the network service issue could be related. Check your /etc/sysconfig/network-scripts/ifcfg-* files and make sure the interfaces you aren't using have ONBOOT=no (they default to yes). Yes, the interfaces default to ONBOOT=YES, but they have NM_CONTROLLED=NO. Anyway, I'll explore, maybe it is a timing issue at boot. What is weird though is that: systemctl ntpd stop works systemctl ntpdate start fails on my cauldron machines, while it works on my mga5 machine. My cauldron machines being at work, I am wondering if this is simply not a firewall issue with the open ports of ntpd. Anyway, as I am the only one having this, I am switching the bug to unconfirmed. Anyone having an idea, please post it here or drop me an email [I cannot post on the dev mailing list these days :/] Status:
NEW =>
UNCONFIRMED Found at last! This is my working place firefall which is closing the ntp port :-/ There is an option in ntpdate to use an unprivileged port: "-u" such that the fix to this issue is to add "-u" in the OPTIONS= of /etc/sysconfig/ntpdate. --- I am reopening the bug because, even without firewalling, the ntpdate.service will fail (please test) if you restart it because it conflicts with a running ntpd.service. Indeed, if ntpd.service is running, as it should, the ntp port being in use, ntpdate must fail with a message saying "port already in use". It works at boot because ntpd.service is demanded to start after ntpdate.service. However, there is two issues here as far as I understand: 1) ntpdate.service is declared as requiring ntpd.service with "bind to". There is not reason for this as both are independent. That's quite crazy because if none of them are running, you start ntpdate.service, it works, it starts ntpd.service and then if you start again ntpdate.service it will fail! 2) This is even crazier if, for instance, network is not up for ntpdate during the boot. In that case, ntpdate.service fails, but still triggers ntpd.service, that will peacefully wait the network to be up. Then, if you want to sync your clock you will restart ntpdate.service, but this one will always fail simply because ntpd.service is running. The solution: Add "-u" by default to OPTIONS in /etc/sysconfig/ntpdate. Even without firewall, this will allow ntpdate to use another port than the one used by ntpd. Cheers. Ever confirmed:
0 =>
1 Ping? If you agree/confirm, I can do it myself (adding -u option for ntpdate OPTIONS), ntp has no maintainer as far as I see :) cheers (In reply to Chris Denice from comment #9) > Ping? > If you agree/confirm, I can do it myself (adding -u option for ntpdate > OPTIONS), ntp has no maintainer as far as I see :) Well, I would vote no. If the problem is a timing issue that should be resolved by dinking around with Wants/After type commands. As indicated I have no problems and no one else except you have indicated a problem. You indicated a firewall problem. Maybe your change will hit more than a few users who expect it to use the standard port. They should not have to limp if your leg is broken. It also means more maintenance for Mageia in the event you could no longer support a non standard setup at some future point in time. My suggestion is you, and you only, modify /etc/sysconfig/ntpdate on your systems to have whatever additional OPTIONS needed to run in your setup. Hi Bit, agreed, for my problem. The second part of my comment #8 mentioned an issue that you should have. Just try to restart ntpdate on your system, it will fail while it should not, which means that you cannot actually sync your clock if it is completely off. That's my only remark here. Maintenance would indeed be needed to remove inter dependency of these services, but the above mentioned bug could already be fixed in the meanwhile by "-u". cheers. Thanks for your feedback. This in INVALID. ntpdate is just a one-off helper service for ntpd, to make sure your clock is in sync before ntpd starts, because if your clock is too far off when ntpd starts, ntpd will not work properly. These two services are bound together by design, and ntpdate is not meant to be used separately or manually. Status:
NEW =>
RESOLVED |
Description of problem: There is a service named "ntpdate.service", which fails all the time as reported by systemctl. Trying to start it manually, systemctl start ntpdate.service also fails. Trying to synchronise time with drakclock also fails. man ntpdate says: ntpdate - set the date and time via NTP Disclaimer: The functionality of this program is now available in the ntpd program. See the -q command line option in the ntpd - Network Time Protocol (NTP) daemon page. After a suitable period of mourning, the ntpdate program is to be retired from this distribution So, why are we providing this service. There is not way to not installing it as "ntp" (which provides ntpd) also force the installation of ntpdate. ntpd is a bit confusing too as dates are not sync immediately but after a while. Anyway, I guess an easy fix would be to remove ntpdate* Cheers, Chris.