Created attachment 648252 [details] System log from Sheevaplug Hello. I have an ARM-powered Sheevaplug running Fedora 17. It seems the real-time clock on this unit is faulty, as on boot the year comes up as 1927. (Note, this bug also applies to PCs with defective RTC chips, so this is not just an ARM problem) Systemd currently starts dhcpd before ntpd, so when dhcpd runs, the date is still 1927. dhcpd fails. If dhcpd is started after ntpd, dhcpd works. Can you please switch the order of ntpd and dhcpd so that ntpd is run first? (note, I'm talking dhcpd, not dhcpcd. Of course dhcpcd has to run before dhcpd, on machines with dhcpcd) Regarding the attached dump of /var/log/messages: Lines 1-55: Network bring-up Lines 63-78: DHCP start. Note failure on line 68. This doesn't happen if time/date is recent Lines 100-116: ntpd gets run (time jumps several decades) Thanks for your help.
systemd provides a mechanism of ordering dependencies to be used in unit files. If there are dependencies missing, bugs should be reported first against the packages providing the affected services, not systemd itself. There seems to be no ordering dependency between ntpd.service and dhcpd.service. If on your system you need to add one, you can add "After=ntpd.service" to dhcpd.service. See: http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F I have no idea if such a dependency is needed by default. Reassigning to dhcp for consideration or closing.
(In reply to comment #1) > I have no idea if such a dependency is needed by default. Reassigning to > dhcp for consideration or closing. By my opinion such dependency is not needed by default. But I'll wait for Jiri Popelka to confirm this. Leaving this Bug in NEW for now.
(In reply to comment #2) > > By my opinion such dependency is not needed by default. But I'll wait for > Jiri Popelka to confirm this. Tomas, do you understand the problem? What would you propose as a fix?
I think this bug is also relevant to platforms that don't have an RTC, such as the Raspberry Pi.
The reason for dhcpd not starting with date being 1927 is probably in failing of gettimeofday() call, which is supposed to give a number of seconds since the Epoch (i.e. 1970). So I suppose that on such a RTC-less machine every service calling gettimeofday() before the time sync is done fails somehow. For example dhcpd calls this via isc_time_nowplusinterval() from libisc-export from bind-libs-lite package so it's possible that BIND if started before ntpd on such machine will suffer from something similar. Ideal fix would be to use something like clock_gettime() instead of gettimeofday() but that's most likely not upstream-acceptable. I'm not sure adding "After=ntpd.service" ordering dependency to each service calling gettimeofday() is good idea. On such a machine the ntpd.service should probably run as soon as possible (basic.target ?). However I'm still considering adding the "After=ntpd.service" to dhcpd.service because it's probably harmless (I hope) and it's generally better for dhcpd if the time sync happens before the start of dhcpd.
(In reply to comment #5) > However I'm still considering adding the "After=ntpd.service" to > dhcpd.service because it's probably harmless (I hope) and it's generally > better for dhcpd if the time sync happens before the start of dhcpd. I checked with systemd guys. Adding "After=ntpd.service" should be really harmless.
(In reply to comment #5) > Ideal fix would be to use something like clock_gettime() instead of > gettimeofday() but that's most likely not upstream-acceptable. Curious. Why would using clock_gettime() not be acceptable? Is it not sufficiently portable? > However I'm still considering adding the "After=ntpd.service" to > dhcpd.service because it's probably harmless (I hope) and it's generally > better for dhcpd if the time sync happens before the start of dhcpd. ntpd is not the only NTP implementation. Perhaps you want rather "After=time-sync.target"? ntpdate.service and chrony-wait.service both order themselves before this target.
(In reply to comment #7) > Curious. Why would using clock_gettime() not be acceptable? Is it not > sufficiently portable? Nothing like that. It's just that ISC seems to be quite picky regarding dhcp patches. But that's just my experience, maybe Adam has another. > Perhaps you want rather "After=time-sync.target"? ntpdate.service and > chrony-wait.service both order themselves before this target. I've thought about chrony too, but didn't know about time-sync.target Thanks.
You might also need to add Wants=time-sync.target, as the respective time-sync services are not enabled by default. This will delay the boot by many minutes when network is not available. I think fixing dhcpd to deal with wrong time should be preferred here.
As an aside... Log files store not just events, but the date and time the event happened. If the date and time is wrong, I think it should be corrected as early in the boot as possible, as incorrectly dated events are very confusing, especially in a forensic situation.
(In reply to comment #9) > You might also need to add Wants=time-sync.target No, do not do that! Only the actual time-syncing service units should pull in this target via a "Wants" requirement dependency. If no such service is enabled, the target should not be activated.
dhcp-4.2.4-23.P2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/dhcp-4.2.4-23.P2.fc18
Package dhcp-4.2.4-23.P2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dhcp-4.2.4-23.P2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-19436/dhcp-4.2.4-23.P2.fc18 then log in and leave karma (feedback).
dhcp-4.2.4-23.P2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.