Bug: timed breaks / alarm clock alarms vanished
asked 2015-02-23 13:31:36 +0300
I have 3 alarms and one count-down timer in use on my Jolla. Last night, I opened the clock app to set the alarm for the morning and for some weird reason the clock app just displayed the clock in the top and the rest of the view was empty. Restarting the app several times did not help.
I first assumed that my alarms and the timer got deleted somehow and tried to create a new alarm, but the newly created alarm was not displayed either.
After restarting the phone, the clock app showed my original 3 alarms and the timer again, but the additional alarm I had created before the boot has not been shown ever. Now everything seems to be back to normal again, all newly created alarms are displayed properly.
I sincerely hope this doesn't affect the actual alarm functionality...
EDIT: This happened to me again yesterday. No idea what I did in the mean time. I'd be also grateful for comments on how to help debug this.
EDIT2: This happened to me again, and I noticed that timed coincidentally does not answer anything on dbus anymore. timedclient-qt5 -i gives
[W] cookies_get:947 - 'query' call failed: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")
Restarting timed (systemctl --user restart timed-qt5.service) fixed things and I got the alarms back.
From the fact that neither tag 'timed' nor 'timed-qt5' are appearing anymore, I assume neither of them was approved? Would anyone care to explain why not? Quite obviously this is strongly related to timed.
Jolly-Jo ( 2015-04-07 10:31:00 +0300 )editTo continue my monologue: Since this situation seems to occur only after uptime is well over 1 week, I try to workaround this one by having timed restart itself (oh, yes) once a day. This obviously relies on the assumption that timed will not go bad after having run only for a day. Also, some self-daemonizing shell script magic was necessary to be able to trigger the restart from timed itself. Let's see where this gets me.
Jolly-Jo ( 2015-04-09 09:45:43 +0300 )editThis indeed sounds like timed crashing. As a system service managed by systemd timed is restarted if it shuts down, in this case it sounds like the restarting has failed as well. An alternative explanation for the missing alarms would be that timed is unresponsive.
@Jolly-Jo: please do attach the journal log here if you encounter this bug again, this kind of malfunction is bound to leave something in the log. You can store the log contents to a file by running the following as root:
journalctl > journal.log.The output of
PMG ( 2015-05-19 09:32:44 +0300 )editsystemctl --user status timed-qt5is useful too, it shows whether the timed-qt5 service is running or not.@PMG AFAIR timed is still listed by ps, so it hasn't crashed. Also the fact that manual restarting fixes the issue contradicts this theory. (Like you mentioned it should be restarted automatically if crashed.) So most likely the dbus part just does not respond anymore.
This only happened to me with uptime > 20 days or so. Since I experienced also other problems with high uptime (lipstick and apps eating memory), my phone now reboots every 7 days automatically. So I'm positive I won't see this again. But in case I do see it, I will post logs.
Jolly-Jo ( 2015-05-21 10:54:42 +0300 )edit@PMG: I have just encountered the same problem, only that
lakutalo ( 2015-05-28 13:45:23 +0300 )editsystemctl --user restart timed-qt5.servicedid not bring back any of my disappeared alarms. Sadlyjournalctldoes not go far enough back to serve you with usable output. I remember that the browser freaked out not allowing any keyboard input to a TJC comment field which lead into a critical storage error and quickly flashing yellow LED. I rebooted the phone and everything worked again. Today I found out that the alarms were gone.