I always get the following errors at boot time: swclock: `/lib/rc/init.d/shutdowntime': No such file or directory swclock is not activated but it looks like openrc tries to run the init script in any case, this fails because /lib/rc/init.d/shutdowntime is missing.
Created attachment 209254 [details] openrc log file
Created attachment 209259 [details] rc-status --all
Created attachment 209260 [details] rc-status --servicelist
I get the same thing with openrc-0.5.2-r2. rc-update shows that swclock is not defined for any runlevel, yet openrc-0.5.2-r2 wants to run it and wants to run a non-existant /etc/init.d/shutdowntime file. Also, rc-update delete hwclock [runlevel] has no effect, openrc still wants to run hwclock. even though I specified that it should run at shutdown, but openrc won't even run it at shutdown too.
Try adding hwclock to the boot runlevel.
I ran into this too, with 0.5.2-r2. Adding swclock to the boot runlevel suprisingly didn't fix things for me (even after several experimental shutdown/startup runthroughs), but after manually restarting it with rc-config restart swclock things have gone swimmingly.
(In reply to comment #5) > Try adding hwclock to the boot runlevel. Setting hwclock to the boot reunlevel fixed it.
I am closing this since it looks like it has been resolved. Please re-open if this is still an issue.
i dont think so. the swclock init.d shouldnt have been stopped if it wasnt started, and ignoring that, there shouldnt have been an error in the first place.
(In reply to comment #9) > i dont think so. the swclock init.d shouldnt have been stopped if it wasnt > started No-one said that. > and ignoring that, there shouldnt have been an error in the first > place. There isn't with the default config. The reporter has removed hwclock from the boot runlevel and one of his scripts "needs clock". As there are now two scripts that provide clock (hwclock and swclock), OpenRC doesn't know which one to start, so it starts them both. swclock correctly errors as the required file does not exist.
the log file shows that 'hwclock' was started implicitly via 'needs clock'. which init.d that is exactly is unknown, but it should get fixed. Daniel: can you run `grep -r 'need.*clock' /etc/init.d/` and post the output ? i dont think the logic of "no preference selected means start *all* providers" makes any sense, but ignoring that, an implicitly starrted swclock should not result in an error during shutdown. i dont see any explanation here as to why the error is being observed.
In response to comment #6: swclock was added for bug #272073 to support systems that do not have a working real-time clock. If your system's hardware clock works, you should be using hwclock, not swclock. Please make sure that you have the correct script added to your boot runlevel. In response to comment #9: The issue reported initially was because the reporter did not have a clock script in his boot runlevel. See comment #5 and the attachment in comment #2 for this. This is a documented step in the openrc migration guide, just below code listing 2.11. Once the reporter followed Roy's suggestion in comment #5, he said the issue was fixed (comment #7). When a clock script is added to the boot runlevel, things work as expected. That is why I closed this bug. This does generate a question about dependencies. I don't know if this belongs on this bug or if we should open another one, but here is the issue this bug illustrates. hwclock and swclock both provide clock and are both installed. If neither service is added to any runlevel but something needs clock, what should openrc do?
(In reply to comment #12) > In response to comment #9: > > The issue reported initially was because the reporter did not have a > clock script in his boot runlevel. See comment #5 and the > attachment in comment #2 for this. The Clock section from the openrc migration guide states: The initscript in /etc/init.d/ has also been renamed accordingly, so make sure it's in the appropriate runlevel. So the guide needs an update in this section and should inform about the two different clock init scripts. Also it should advise the user to add the choosen init script to the boot runlevel instead of the "appropiate". > This is a documented step in the openrc migration guide, just below > code listing 2.11. Once the reporter followed Roy's suggestion in > comment #5, he said the issue was fixed (comment #7). > > When a clock script is added to the boot runlevel, things work as > expected. That is why I closed this bug.
Created attachment 209963 [details] openrc-migration.diff Attached is a small patch for the openrc migration guide. I can open a documentation bug if it is okay. Thoughts? Recommendations?
Created attachment 209972 [details] openrc-migration.diff A slight wording change for the patch. Billy, let me know what you think about this.
(In reply to comment #15) > Created an attachment (id=209972) [details] > openrc-migration.diff > A slight wording change for the patch. > Billy, let me know what you think about this. I am fine with the changes, looks a bit clearer now. This is now bug #292886, so add further improvements there.
The documentation is up to date. Pybugz wouldn't close for some reason, so I am trying again with the web interface.
summarizing the bug and updating documentation still doesnt address any of my questions in comment #11
(In reply to comment #11) > i dont think the logic of "no preference selected means start *all* providers" > makes any sense So open a bug about changing it then. > but ignoring that, an implicitly starrted swclock should not > result in an error during shutdown. i dont see any explanation here as to why > the error is being observed. Re-read the above - no-one said this happened. I think you're mis-reading it as the file referenced has the word shutdown in it.
shutdown or boot, there is still no explanation/fix for why an error was observed. if swclock is started for the first time, it shouldnt throw up on a missing file. this is the most common code path: - user upgrades to new openrc - user wants to use swclock - user removes all clock provides - user adds swclock - user reboots - swclock is not stopped because it was never started - user sees error during boot - user files bug report
To clarify, my path was: - removed hwclock from boot runlevel before switching to openrc (due to ignorance) - switched to openrc 0.4.8 - updated to openrc 0.5.2-r2 - rebooted - got the error at bootup: swclock: `/lib/rc/init.d/shutdowntime': No such file or directory - swclock stop was never triggered on shutdown, so the error appeared each bootup - manually restarting swclock created /lib/rc/init.d/shutdowntime, and from then on things worked (from this I learned that I really should be using hwclock anyway, which I've now switched to).
The only issue remaining is that swclock fails to start if it hasn't ever been stopped. /lib/rc/init.d/shutdowntime doesn't exist in this situation, and that is what causes swclock to fail to start. This can be verified by running rc-service swclock start on a system that doesn't use swclock. Should this generate a failure or should swclock go ahead and start successfully? If it doesn't start successfully, should we update the documentation and tell users to run rc-service swclock stop before they reboot if they are using swclock?
http://roy.marples.name/projects/openrc/changeset/80d4ce3a11e28394724cff32073302265933c06d This should do it
As a secondary item to this, it would be nice to have a way to flag a init script as not to be chosen automatically as a provider, and require that it be explicitly configured instead.
Just remove the provide directive from the init script?
thanks Roy, that should do it. i'll address the providers in a diff bug. Daniel: can you please run the grep i posted in comment #11 ?
(In reply to comment #26) > thanks Roy, that should do it. http://roy.marples.name/projects/openrc/changeset/0de1d18d41950dc36a0c38ff5bf0ef0fc5c73801 I tested this time :)
(In reply to comment #26) > thanks Roy, that should do it. i'll address the providers in a diff bug. > > Daniel: can you please run the grep i posted in comment #11 ? > Sorry Mike, I somehow missed this. Here is the output of the grep as requested: grep -r 'need.*clock' /etc/init.d/ /etc/init.d/syslog-ng: need clock hostname localmount
roy: Nope, you're not quite getting me. Taking out the provide from swclock makes hwclock always start :-(. If there is no {sw,hw}clock in the runlevels, then I want only hwclock to be considered. If I manually add swclock, then hwclock should not be brought in. Alternatively, weights for providers, so we can deterministically say which one will be picked when none are explictly configured.
(In reply to comment #29) > roy: > Nope, you're not quite getting me. > Taking out the provide from swclock makes hwclock always start :-(. This is how it should work since after you remove the provide from swclock hwclock is the only provider for clock. > If there is no {sw,hw}clock in the runlevels, then I want only hwclock to be > considered. If I manually add swclock, then hwclock should not be brought in. The second part of this statement is how things work as they stand. If you remove hwclock from your run levels and add swclock, swclock will be run and hwclock will not. > Alternatively, weights for providers, so we can deterministically say which one > will be picked when none are explictly configured. Hmm,do we really want openrc to try to figure out which service to run if there are multiple providers, or should we require that one be configured? My vote would go toward requiring one to be configured. In the case we are talking about, hwclock and swclock should not both be run on the same system anyway.
the swclock error has been fixed, and the remaining issues have been split
I'm fine with requiring that one be configured, but then we must throw large warnings if the user has none configured. This should be as a general concept, not hardcoded for {hw,sw}clock.
