Saved Alarms and Timers Disappearing After Reboot

[AlanBreen]

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.4.0.58
HARDWARE (XA2, X10, X10 II, …): XA2
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?): Yes

DESCRIPTION: Saved Timers and alarms disappear after reboot (re start)

PRECONDITIONS: Nil

STEPS TO REPRODUCE:

1. Save a Timer or Alarm
2. Re boot phone
3. Saved Tmers and alarms disappear

EXPECTED RESULT: Saved Timers and Alarms are still present after re boot.

ACTUAL RESULT: Timers and Alarms missing

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

[nas]

Did you check if your device has free space? Once I had the same issues was because of no memory (and latter because of broken btrfs)

[AlanBreen]

Plenty of memory. How might I check on the btrfs issue?

[sigurg]

No need, Sailfish on XA2 doesn’t even use BTRFS.

[pherjung]

I just tried on my X10 II on 4.4.0.64 and couldn’t reproduce it.

I need more information to be able to reproduce it. Ideally, you reboot your phone and describe everything you do. The more steps, the better.

[AlanBreen]

I did a fresh reinstall. I’ve had no issues since then.

[razcampagne]

I have the same issue almost each time I reboot. The thing is that I only reboot when my phone is an inconsistent state, mainly when I stumble upon the gps not working problem.
I have an XPeria 10III.

[canne]

I found this thread since for the first time (ever) I have this same issue: all timers and alarms are cleared at each reboot on my Xperia 10III 4.5.0.24. What did I change since last time I actually used alarms or timers? I installed the alternative fonts following these instructions elsewhere in the forum: Change Default Font - #2 by nephros . I also installed LXC Containers application from Chum and has rebooted after that a few times without looking at the alarms. To be studied.
2024-01-13 how I fixed my particular problem by resyncing user’s timed-qt5.service:

Summary

• If after the restart of the phone, before you launch the jolla-clock application you get an empty list from the command timedclient-qt5 -L (if not available in /usr/bin, install it with devel-su pkcon install timed-qt5-tools) ;

• If there is a file ~/.timed/events.data which contains the timer and alarm settings from the jolla-clock application ;

Then you are in the same same situation I was, and you can attempt the below procedure to recover :

1. Check the file, generated from jolla-clock application settings in ~/.timed/events.data ;

2. If it contains your previous settings or you are otherwise satisfied with it, skip the next step ;

3. Otherwise, use the jolla-clock application and set the alarms and timers as you want, and quit the application and go to point 1 ;

4. Give command systemctl --user restart timed-qt5.service ;

5. Give command systemctl --user status timed-qt5.service and verify that the service is running ;

6. Verify that a similar list (but in different format) than in ~/.timed/events.data file is given out by the command timedclient-qt5 -L ;

7. Open the jolla-clock application and verify that all alarms that you want to be enabled are enabled ;

8. Quit the jolla-clock application ;

9. Restart the phone ;

10. Open the jolla-clock application and verify that all alarms and timers and their settings are persistent - that they have survived the restart.

[dcaliste]

It never occured to me, so I can only ask questions… The list of alarms are saved in ~/.timed/events.data. There even is a backup of this file in this directory. I guess when the timed daemon is started, this file is read and alarm restored accordingly.

If it happens to you again, may you look at this file, check that it exists, is readable and contains accurate data (its a plain text file) ?

EDIT: oops, sorry @canne I didn’t read your summary yet when writing this…

[razcampagne]

I just stumbled upon this problem and I had a look at the events.data files.
events.data.bak contains all my alarms but
events.data only includes alarms from the calendar.
Would it be that the calendar overwrites the whole file?

[dcaliste]

Would it be that the calendar overwrites the whole file?

No, that’s not possible as far as I can tell. This file is handled by timed alone. There is no concurrent access. The calendar is asking to add or remove alarms via timed client library (which talk to the timed daemon via D-Bus).

Nonetheless, that’s an interesting observation. It’s not a file systyem issue, or the file that is not present at reboot, or whatever related to this file. The fact that the calendar alarms are still there (and the calendar never “reset” its alarms on reboot), means that something is removing all clock alarms, either during shutdown or during restart… That’s a lead to follow : finding what part of code can flush the clock alarms and see what can trigger it.

[razcampagne]

It happened again today and this time events.data still had the alarms I set before the reboot. But jolla-clock’s UI remained desperately empty.
I’m not sure what I could try to help find the issue.

[nephros]

Happened again now.

1. Device had relatively long uptime (Two weeks or so)
2. Shutdown was triggered by running out of power
3. Therefore, plugging in a charger cable booted up to ‘charging’ screen (is that ‘actdead’)?
4. After a bit of charging, boot to proper mode

Can it be that charging screen has e.g. timed running but home not mounted so it can’t read/write alarms?

Is a boot from charging screen to proper OS a real reboot, or does booting continue from charge screen?

Theory being that timed is initialized with empty config, and later writes that to the data file once it becomes writable?

I that theory holds, maybe all that’s needed is something like a RequireMountsFor dependency in the systemd unit file.

Edit: Also, I notice that jolla-usersetup service was reported as failed. That one is a dependency of pre-user-session.target which is the one that the timed service has a ‘WantedBy’ dep on.
Not sure if related, but maybe that target isn’t reached in proper time?

[nephros]

Another ones of those ran out of battery episodes. And: NO BUG!

All alarms there. Also, jolla-usersetup does not show up as failed.

My conclusion is that there is is indeed a race condition in systemd services. And it’s causing /home not being mounted at the right time.
Because looking at the script that’s run by jolla-usersetup, no home is the only thing I can see that would cause that to fail.

[nephros]

Likely duplicate:

[Clock app] Scheduled alarms fail

For a couple of times now I have overslept because the alarm in the native Clock application fails to go off at the scheduled alarm time. When I wake up later on and look the Clock application, the active alarm at 4:40 is still active and nothing seem to have happened at the scheduled time it should have alarmed. The chosen hour comes, but nothing happens. The issue does happen on the current OS, but it did also happen in previous iterations too. Started happening “as of lately”, I wish I coul…

[demislition]

@nephros That bug report of mine seems to be of different thing. In my case the scheduled active alarm doesn’t activate (=go off) at the preset time, and when I go look the alarms after an alarm has failed to activate, the alarm in question is still there and still continues to be marked active.