Hi, thanks for reporting this bug.
As there is no maintainer for this package I added the committers in CC.

(Please set the status to 'assigned' if you are working on it)

CC: (none) => ennael1, guillomovitch
Blocks: (none) => 2120
Source RPM: (none) => ntp

(In reply to comment #1)
> Hi, thanks for reporting this bug.
> As there is no maintainer for this package I added the committers in CC.
> 
> (Please set the status to 'assigned' if you are working on it)

I am not even sure I know which package is at fault. Do we start with the assumption that it is systemd?

I would have expected ntp to be installed as a system service which MCC would see and list in its controllable services.

That neither MCC nor the non-systemd can tell ntpd should be started is, perhaps, the core problem. As a side issue, drackclock cannot start it either, or is that also the core issue?

well does it work if you do systemctl ntpd.service start

(it was you that report a similar bug)

anyway this bug is the tracker of systemd ;)

sorry '?' was missing twice.

In fact it works with systemd but not with initscript ?

(chkconfig for checking so)

Yep, that's it. Because I now cannot boot this system with systemd I have discovered that ntpd isn't starting and cannot be started by "the usual methods" described above.

A simple "ntpd" entered in a console will get it going, but then that is what is supposed to happen during boot, or when specifically selected in drakclock, or when enabled via the system services checklist in MCC.

I'll try removing and then re-installing ntp (and client) and see if that makes a difference. Back in a few minutes, still editing some video on this box.

I used rpmdrake to remove ntp and ntp-client. Then I re-installed using rpmdrake. I WAS ABLE to start ntpd using drakclock, and "ntpd" has reappeared in the list of MCC managed services. On re-boot, ntpd started correctly. On the face of it the problem has gone away.

However, I will check later today (after some sleep) to see if installing ntp when prompted by drakclock (because I had been trying openntpd and drakclock doesn't like that) is what did the damage.

I repeated the operations which led to the first appearance of this fault. I used rpmdrake to install openntpd which caused the removal of ntp and ntp-client. I re-booted and used drakclock to tick the ntp checkbox. This resulted in the prompt to download and install ntp and ntp-client, which I accepted, resulting in openntpd being uninstalled.

I rebooted and ntpd is running. ntpd is listed in the services managed by MCC. Everything looks (almost) normal. 

The problem has gone away.

Please dispose of this bug report accordingly (I will now focus on finding out why I cannot boot using systemd).

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

Hi Richard,

Has the problem gone away since drakxtools 13.81 (released yesterday)?

Before drakxtools looked for the file /var/lock/subsys/ntpd to determine if ntpd was running, a file which is not created when systemd controls ntpd. With drakxtools 13.81 this has been changed and might explain why your problem has now disappeared.

I have info related to this bug:
When I look at MCC -> System services 
ntpd is flagged to be started at boot, but is marked as stopped (reproducibly) - however "ps -A | grep ntpd shows" a running ntpd.

Looks like ntpd is really running, but there is a problem in drakconf.real - probably a bug should be filed on that - it is practically not possible to start or stop services there.

/var/log/syslog also appears to indicate that ntpd does its job as it should
Initially there are messages like

Feb 14 14:24:47 pcjuergen ntpd_intres[809]: host name not found: 0.europe.pool.ntp.org

but than

Feb 14 14:24:52 pcjuergen ntpd[696]: Listen normally on 4 eth0 fe80::221:9bff:fe72:78c5 UDP 123
Feb 14 14:24:52 pcjuergen ntpd[696]: peers refreshed
Feb 14 14:24:52 pcjuergen ntpd[696]: new interface(s) found: waking up resolver
Feb 14 14:24:54 pcjuergen ntpd_intres[809]: DNS 0.europe.pool.ntp.org -> 46.166.157.106
Feb 14 14:24:55 pcjuergen ntpd_intres[809]: DNS 1.europe.pool.ntp.org -> 77.245.91.218

syslog appears to be a good source for verifying.

CC: (none) => juergen.harms

I can add only a little bit because I have been chasing so many problems I can easily forget, in the time (long time) it takes to reboot, what it was I was checking this time ;-(

First to Remco, 2012-02-13 19:34:52 GMT was only ten or fifteen minutes after it started to work again. I am usually pretty prompt at taking updates but I can check the times in my logs.

Juergen, the only little bit I can add to your description (which I can relate to what I am seeing) is that the entry in MCC Services list for ntpd which was there, then disappeared and reappeared when I thought it was fixed, is now definitely not there again. 

I'll go do some log diving now....

Now that is odd. There are strange huge gaps in some logs. Looks like only /var/log/messages (and syslog) have a record (possibly partial?) of 13th Feb. /var/log/user.log skips it completely - disappears from 17:49 on Sunday 12th to 01:14 on Tuesday 14th.

I opened this bug at 2012-02-12 23:07:07 GMT from the affected PC. It had been up since 22:22:42 GMT. I had closed down at 19:22:14 GMT to travel here, so I got it started after about an hour of trying to get past the boot hang. It was up until 03:15:59 GMT Monday 13th. Some of the bug comments above were entered on the affected PC during this time. So, it was functioning but without creating a single entry in user.log.

The /var/log/user.log entries started again in the wee small hours of Tuesday morning; 01:44:15 which is a long time after I started using this PC on Monday evening.

Whatever is going wrong on my Cauldron install, it is affecting logging too. 

Richard

I complete a fresh install tonight on a fresh drive from a French ftp site. From first boot I discovered that the grub boot commands do not use systemd, so all subsequent boots have been old-style. 

I configured ntpd during the installation and it has stayed configured. Also MCC drakclock shows the checkbox ticked and the server is still correctly set to Europe|United Kingdom: uk.pool.ntp.org.

MCC Services shows ntpd and indicates that it is stopped and set to run on boot.

In other words, everything looks to be the way it should be. I won't touch it until tomorrow after I have had a chance to check out the rest of the system.

Tried a boot tonight using init=/bin/systemd. It worked, though it was somewhat slower than an old-style init boot. Looked like it is hanging waiting for something to time-out, but that's not the point. On completion of the boot we have ntpd running and everything in MCC looks as it should. It may just be the clean system from a fresh install, but it looks OK now. 

If I can pluck up the courage I will try disabling and re-enabling it using drakclock. I'll report tomorrow on that.

drakclock in MCC is now working as advertised.

I tried to read with fresh eyes, but it's difficult to figure what the exact problem is there. Especially if you add graphical configuration interface (MCC) in the mix.

If the problem is than ntpd doesn't start with sysinit (as reported by "service ntpd status"), despite being enabled (as reported by "chkconfig --list ntpd"), then it's indeed a ntp package problem, altough the bug title should be simplified to avoid a double negation.

If the problem is than MCC (drakxservices, actually) output isn't consistent with previous commands results, then it's an MCC issue, and the bug should be updated accordingly.

The problem has gone away, and apparently stayed away. It did not re-appear after a fresh Beta1 install on 24 Feb. I think it is safe to close it now.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => WORKSFORME