Bug#819019: fake-hwclock: allow the saved time to go backwards under normal use
> What we *can* do is instead add an extra declaration of system time > based on the build/release date of the particular version of the > fake-hwclock package in use, and refuse to back to a date before > *that* unless --force is used. How does that sound? That sounds like a good policy in general, and it would solve my concerns. Thanks! On Fri, Apr 8, 2016 at 10:50 AM Steve McIntyre <st...@einval.com> wrote: > [ Including a CC to Robie from the previous bug #763589... ] > > Hey guys, > > On Tue, Mar 22, 2016 at 11:37:56PM +, Roddy Shuler wrote: > >Package: fake-hwclock > >Version: 0.10 > > > >On bug #763589, protection was added around the save operation so that the > >saved time cannot go backwards without forcing. While this clearly > >mitigates the race condition of concern, I don't believe it is an > >acceptable solution for normal users. > > > >Consider the following use case... > > > >1. The user accidentally sets a wrong time to a date in the future -- for > >example, sets the year to 2017 rather than 2016 > >2. The fake-hwclock.data file is written with the future time > >3. The user then realizes the mistake, and tries to fix the time back to > >the year 2016 > >4. Now, the cron job and service will not update the fake-hwclock.data, > >since it appears that the current system time is in the past (relative to > >the invalid saved time) > >5. On reboot, the clock reverts to the future date in the year 2017, and > >continues to do so on every reboot for the next year (unless the user is > >advanced enough to know to manually run the script with the force flag) > > > >Other than races on startup, the normal case is that the system time will > >not go backwards unless it was intentionally changed (either by a user or > >by an update from an NTP server), so I don't believe it makes sense to > >reject such saves by default. (The protection for loads, on the other > >hand, is clearly needed.) > > > >For my specific use case, I simply reverted to the original behavior > >without any protection against saving, but I suppose the upstream solution > >would require an alternate solution to the race reported on #763589. > > Right. > > And in #763589 we have: > > >I've observed a system with a correctly working fake-hwclock > >(originally initalised by NTP) set its time back to shortly after the > >epoch, including in /etc/fake-hwclock.data. > > > >I believe this happened because "fake-hwclock save" was called after > >boot before "fake-hwclock load" was called. > > > >I think this happens in the case of a very early shutdown event that > >calls "/etc/init.d/rc 0" before "/etc/init.d/rcS" has completed. > > > >In my case, I have a Raspberry Pi rigged with an external shutdown > >signal hooked up via udev. If the signal is "high" at boot time, then > >the Pi shuts down without fully booting up. > > > >I'm not entirely sure that this is the cause, but the race is there. > > We have two conflicting requirements here, I think. Thanks for > explaining your logic, both of you. > > The problem is that I don't think there's a good solution to both > problems here. We can't *know* that the system time has been read from > fake-hwclock.data before calling "save". I briefly considered adding a > "I've seen this" flag that could be set in "load", but that's no > guarantee at all - if we power down unexpectedly then it'll be set > already at next boot. > > What we *can* do is instead add an extra declaration of system time > based on the build/release date of the particular version of the > fake-hwclock package in use, and refuse to back to a date before > *that* unless --force is used. How does that sound? > > Or can you think of any other possible fixes here? > > [ I've also just realised that I'll need to go back and re-add > initramfs support now that we automatically attempt to mount and > fsck /usr in the initramfs. Joy \o/ ] > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "I suspect most samba developers are already technically insane... Of > course, since many of them are Australians, you can't tell." -- Linus > Torvalds > > -- *Roddy Shuler* | +1.585.530.7960 | Endless
Bug#819019: fake-hwclock: allow the saved time to go backwards under normal use
Following up, another important use case (which turned out to be what caused problems for us in the first case)... At least with some hardware implementations, upon disconnecting and reconnecting the battery, the hardware clock is initialized to a random date/time, which can easily be years in the future. Again, once in this state, the fake-hwclock can never be set back properly under normal usage, and thus overrides the real hwclock on every future boot. -- *Roddy Shuler* | +1.585.530.7960 | Endless
Bug#819019: fake-hwclock: allow the saved time to go backwards under normal use
Package: fake-hwclock Version: 0.10 On bug #763589, protection was added around the save operation so that the saved time cannot go backwards without forcing. While this clearly mitigates the race condition of concern, I don't believe it is an acceptable solution for normal users. Consider the following use case... 1. The user accidentally sets a wrong time to a date in the future -- for example, sets the year to 2017 rather than 2016 2. The fake-hwclock.data file is written with the future time 3. The user then realizes the mistake, and tries to fix the time back to the year 2016 4. Now, the cron job and service will not update the fake-hwclock.data, since it appears that the current system time is in the past (relative to the invalid saved time) 5. On reboot, the clock reverts to the future date in the year 2017, and continues to do so on every reboot for the next year (unless the user is advanced enough to know to manually run the script with the force flag) Other than races on startup, the normal case is that the system time will not go backwards unless it was intentionally changed (either by a user or by an update from an NTP server), so I don't believe it makes sense to reject such saves by default. (The protection for loads, on the other hand, is clearly needed.) For my specific use case, I simply reverted to the original behavior without any protection against saving, but I suppose the upstream solution would require an alternate solution to the race reported on #763589. -- *Roddy Shuler* | +1.585.530.7960 | Endless
Bug#815833: Fake-hwclock: consider mtime of root (/) if no saved file
Perfect! Thanks for your suggestion, Steve. That does sound like a cleaner solution than what I had proposed. Roddy On Mon, Feb 29, 2016 at 5:28 PM Steve McIntyre <st...@einval.com> wrote: > Hi Roddy, and thanks for getting in touch! > > On Wed, Feb 24, 2016 at 09:27:26PM +0000, Roddy Shuler wrote: > >Package: fake-hwclock > >Version: 0.9 > > > >Upon first use of fake-hwclock, if the device does not have a > >battery-backed clock (and has not saved fake-hwclock.data yet), the clock > >will typically start at Jan 1, 1970 UTC. This has the following > >repercussions: > >- Before manually adjusting the time, it will be behind other files on the > >system > >- Manual adjustment of the clock via a UI with a mouse will require > several > >clicks to increment the year from 1970 to the current > >- If the user does not adjust the time, website certificates will be > >rejected as not yet valid > > > >While a fake clock is never perfect, we can get closer to reality by > keying > >off of the modification time of a file or directory, so that on first boot > >the clock will effectively be set to a time that is no earlier than the > >time at which the file system was built. Using the root directory (/) > >seems safest as it is a directory that can be assumed to always exist. > > OK, I see your logic but I'm not sure it's the way I'd choose to > go. What you *have* identified is that there's a hole in the package > such that it may not get to save a state file before rebooting. I'm > thinking a better fix would be to add a call to "fake-hwclock save" in > the postinst. How does that sound? > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "Further comment on how I feel about IBM will appear once I've worked out > whether they're being malicious or incompetent. Capital letters are > forecast." > Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html > > -- *Roddy Shuler* | +1.585.530.7960 | Endless
Bug#815833: Fake-hwclock: consider mtime of root (/) if no saved file
Package: fake-hwclock
Version: 0.9
Upon first use of fake-hwclock, if the device does not have a
battery-backed clock (and has not saved fake-hwclock.data yet), the clock
will typically start at Jan 1, 1970 UTC. This has the following
repercussions:
- Before manually adjusting the time, it will be behind other files on the
system
- Manual adjustment of the clock via a UI with a mouse will require several
clicks to increment the year from 1970 to the current
- If the user does not adjust the time, website certificates will be
rejected as not yet valid
While a fake clock is never perfect, we can get closer to reality by keying
off of the modification time of a file or directory, so that on first boot
the clock will effectively be set to a time that is no earlier than the
time at which the file system was built. Using the root directory (/)
seems safest as it is a directory that can be assumed to always exist.
Below is a proposed change to the "load" case of the fake-hwclock script:
load)
if [ -e $FILE ] ; then
SAVED="$(cat $FILE)"
SAVED_SEC=$(date -u -d "$SAVED" '+%s')
else
echo "Unable to read saved clock information: $FILE does not
exist"
echo "Using modification time of root directory (/) as saved
time"
SAVED_SEC=$(stat -c %Y /)
SAVED=$(date -u -d "@$SAVED_SEC" '+%Y-%m-%d %H:%M:%S')
fi
NOW_SEC=$(date -u '+%s')
if $FORCE || [ $NOW_SEC -le $SAVED_SEC ] ; then
date -u -s "$SAVED"
else
echo "Current system time: $(date -u '+%Y-%m-%d %H:%M:%S')"
echo "fake-hwclock saved clock information is in the past:
$SAVED"
echo "To set system time to this saved clock anyway, use
\"force\""
fi
;;
--
*Roddy Shuler* | +1.585.530.7960 | Endless
Bug#733397: libstruts1.2-java: FTBFS: [javac] /«PKGBUILDDIR»/src/share/org/apache/struts/action/ActionServlet.java:53: error: package org.apache.commons.collections does not exist
There were two build errors... The first (per the subject of the bug) is fixed by adding a build (and I assume run-time) dependency on libcommons-collections-java The second (a few lines later in the build output) is due to ant.properties calling out the version of jsp.jar that is provided by libservlet2.5-java, whereas the debian/control specified a dependency on only libservlet3.0-java. I fixed this by calling out version 2.2 rather than 2.1 in ant.properties (assuming the intention was to change from libservlet2.5 to libservlet3.0). Roddy
Bug#733012: mojarra: FTBFS: error: package javax.faces.component.html does not exist
The root of the problem is a little earlier in the build log than the provided snippet. javax.faces.component.html should be generated by a previous step in the build, which is failing due to missing dependency/classpath for commons-collections. I fixed by added a build dependency in debian/control on libcommons-collections-java, and adding commons-collections.jar to the classpath in debian/classpath-debian. I'm not sure if there should also be a runtime dependency on libcommons-collections-java. I assumed not since there were no runtime dependencies specified on the other libcommons-*-java packages. - Roddy Shuler
Bug#733434: maven-plugin-testing: FTBFS: Missing required artifact: org.apache.maven.plugin-testing:maven-test-tools:jar:debian
The problem is in 0002-fix-dependency-on-maven-test-tools.patch... The version for maven-test-tools needs to be updated from 1.2 to 1.3 to match what is being generated by the package.
