Time gets reset on powerloss

[Ysblokje]

Here's one my son discovered : when you pull the plug during your session it resets the time remaining back to the original state.
This is on Mint XFCE 19.1 .

[Eduards Bezverhijs (mjasnik)]

I need more details about this, like:
* how much time spent was before pulling the plug and how much time is left right after booting up?
* is time for today reset or all of the times (week & month included) are reset?
* what exactly is meant as original state?

In addition please add timekpr.log file right after computer is booted after pulling the plug.
Please add Your sons conf and time files before and after pulling the plug from /var/lib/timekpr/work/ and /var/lib/timekpr/config/ directories.
You can send them via e-mail, if You feel this information should not be shared here.

Timekpr-nExT is saving time every 30 seconds by default, if "original state" and time let after pulling the plug is +/- 30 seconds apart, it might be normal behaviour, more than that - it's most likely a bug.

[Ysblokje (ysblokje)]

Sorry to respond so late, your response ended up in my spambox.

He pulls the plug when his time is close to empty or if he does get logged out logs back in and in the few seconds he has.

From what I have seen all his time spent gets reset to 00:00:00, it might be for others but he's the only user of that machine.

I will email the files to you.

[Ysblokje (ysblokje)]

As promised.
Files after unplugging.

Minze

On Mon, Jul 8, 2019 at 1:35 PM Eduards Bezverhijs <email address hidden> wrote:

> I need more details about this, like:
> * how much time spent was before pulling the plug and how much time is
> left right after booting up?
> * is time for today reset or all of the times (week & month included) are
> reset?
> * what exactly is meant as original state?
>
> In addition please add timekpr.log file right after computer is booted
> after pulling the plug.
> Please add Your sons conf and time files before and after pulling the plug
> from /var/lib/timekpr/work/ and /var/lib/timekpr/config/ directories.
> You can send them via e-mail, if You feel this information should not be
> shared here.
>
> Timekpr-nExT is saving time every 30 seconds by default, if "original
> state" and time let after pulling the plug is +/- 30 seconds apart, it
> might be normal behaviour, more than that - it's most likely a bug.
>
> ** Changed in: timekpr-next
> Assignee: (unassigned) => Eduards Bezverhijs (mjasnik)
>
> ** Changed in: timekpr-next
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1835651
>
> Title:
> Time gets reset on powerloss
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/timekpr-next/+bug/1835651/+subscriptions
>

[Eduards Bezverhijs (mjasnik)]

I have checked files You sent, but there is not enough information, e.g. log files :(

The files I need are:
*) /var/lib/timekpr/work/*timo*
*) /var/lib/timekpr/config/*timo*
*) /var/log/timekpr.log

Please do the following:
*) observe how much time he has before pulling the plug (make screenshots if needed), observe the current time as well, gather the files mentioned above
*) pull the plug, reboot
*) right after reboot, observe how much time he has after pulling the plug (make screenshots if needed), observe the current time as well, gather the files mentioned above

That would give me enough information to start looking for bug.

Thanks.

[MCH (mchilli)]

Hi there i can confirm this bug.
After plugged out the power supply (without a battery in the device) and repower the notebook, the timelimit will be resetted.

I have attached the files you wanted.
The "weird" stuff is happening in line 15435 of the log file.

Hope this will helped, because my son will use this bug for his benefit. :)

[Eduards Bezverhijs (mjasnik)]

Sure he will :)
I'll try to check what's up, but I can not promise fast result as I have very busy schedule in upcoming days / week.

[Eduards Bezverhijs (mjasnik)]

I was able to reproduce this and what it looks like that for some reason or other file that has been modified has not been synced to disk, which is a little surprise to me.
So now I have to figure out why is this and how to circumvent the behaviour.

[Eduards Bezverhijs (mjasnik)]

Investigated more and found that I can trigger this quite often in VM, but not that often on actual HW.
The issue is that file is not _actually_ physically written to disk before pulling the plug, although from code perspective it's saved and closed, therefore should be on disk (but apparently it's not).

The only reliable solution is to make backup files of every config / time files, because if changed file is not saved (and actually flushed + synced to disk), it may get corrupted or empty after reboot.
So when primary file is corrupted or empty, try to load backup file instead. I made a proof of concept and so far it looks plausible.

[MCH (mchilli)]

So you mean, that the primary files and the backup files are saved asynchroniousally? Maybe you backup the files in a longer intervall (e.g. 5 min), so you can be sure that one file are always readable and also to prevent that both files are written at the same time.

Sounds good hope this will work! :)

[Eduards Bezverhijs (mjasnik)]

Actually I'll backup them just before the modifications (so every 30 secs for .time files) and that should be fine.
See, if backup fails (someone pulls the plug), original is still intact, good, but if write to file fails, then we have a backup already, good.
Now I need to refactor config load and save :)

[Eduards Bezverhijs (mjasnik)]

I fixed this bug (hopefully), I used a little different config / control file update routines as well.
I could not reproduce the issue multiple times I tried, backup file saves the day.

There will be multiple additional fixes in this release, please try beta when it's built, usually it takes up to one hour.

Please reboot normally at least once :)