maemo.org Bugzilla – Bug 1112
Recurrent alarms do not work reliably
Last modified: 2009-12-23 18:32:25 UTC
You need to
before you can comment on or make changes to this bug.
I have set up a recurring daily alarm at 9 AM. It rarely rings. It seems as
the alarms only show up when the device is online.
Today, for example, it didn't ring. At about 1 PM I went online to check
weather reports. As soon as the tablet connected, I got an alarm popup for
9 AM alarm.
Please re-test it. If problems still occurs. Prodive exact steps to reproduce
If problem does not appear any more, clode bug.
I still have the same alarm, set to sound every day at 9 AM. It almost never
rings at 9 AM. Every day the first time I go online, I get an alarm dialog
saying this is my 9 AM alarm. One night I had left the device online, and in
the morning I was awakened by the alarm, that's why I said "almost never" above.
My attempts to reproduce this with once-only/weekly alarms set to sound in 1
minute's time were unsuccessful: the alarm sounded in 1 minute irrespective of
whether the device was online or offline at the time.
I have created a new daily alarm at 10 AM, and will try to see whether it still
works after a couple of days.
Results of my experiment after two days:
1. The first morning (wifi on) I got both alarms. (I dismissed the 9 AM one
immediately. The 10 AM one was a little strange: I heard about three or four
notes and then the device went silent. When I checked a few hours later, I saw
a dialog box for the alarm.)
2. The second morning (wifi off) I got the 10 AM alarm, but not the 9 AM
alarm. Going online later did not cause the missed 9 AM alarm to appear this time.
I have to say that I do not understand what is happening, nor how to reliably
reproduce the missing alarm problem.
After a few weeks of testing, all I can say is this: I cannot discern any
pattern, but the alarm feature is unreliable. Very rarely I've had both alarms
go off on time. Sometimes one of the alarms that were missed appears briefly
(without any sound effects) the first time I go online during a day.
(This should be a separate bug, but I though I'd mention that I set up alarms at
9 AM and 10 AM, but after the switch to daylight savings time the N800 now
thinks I want alarms at 10 AM and 11 AM.)
I tried to replicate this in the wild and could not. I set mode to offline,
alarm to 11:58 pm (my home time) and it went off as intended.
However, I have discovered other alarm issues and bugged them; please vote!
I've ran into this as well on my N800 with the latest release, and can
replicate it the following way:
1. Set the alarm for a time in the future (I've tried with 3+ hours in the
2. Disconnect wifi connection (NOT setting device to offline mode, just simply
disconnect on the wifi menu), and let device idle (so that the screen turns
3. At a time beyond when the alarm was set for, connect to wifi and the alarm
If I leave the wifi connected, and repeat the process the alarm goes off each
time without fail. It also doesn't seem to matter if it is plugged in or on
agreed. Having the same issue w/ OS2008 and Nokia n810. Set 5 weekly
recurring alarms and if the device is turned off, the alarms will not sound.
Recently flashed to new OS2008 2.2007.50-2. Alarms worked previously before
the I flashed the new OS. No discernible pattern. Alarms will chime when the
unit is powered on. If memory serves me correct, wasn't waking up with FM
radio added to the new OS build? Has anyone looked at those changes to see if
that may be the cause?
So this happens both with N800 and N810.
Having a good way to reproduce this would be appreciated, but I understand that
it's hard. :-/
When I saw Andre's comment, I decided to set a daily alarm and see if I can
reproduce the bug on Diablo on a N810.
During the first two or three days the alarm worked normally. After that I
stopped hearing the alarms in the morning. I'm pretty sure I haven't slept
through them since my cell phone is set to ring 30 minutes earlier, and I hear
that one. When I tap the screen to wake up the N810, I see the alarm dialog
waiting to be dismissed.
Unfortunately, now I don't know whether I've reproduced bug 1112, bug 1146 (my
N810 is set to autoconnect to wifi and is therefore always online), or bug 1691
(the alarm may be inaudible because the sound is muted, duh!). I've checked
that the volume is unmuted tonight, so I'll see what happens next morning.
FWIW I strongly suspect 1112 and 1146 are duplicates. The bug for me was
always that the alarm app failed to alarm me after a few days passed since my
setting up of the alarm. I guessed it had to do with online/offline mode
because of the strange belated appearance of the alarm popup when I made the
device go online.
I said "I'll see what happens next morning". What happened was that I woke up
in the afternoon and saw that the battery of my N810 was empty (I blame getmaps
that I left running overnight).
The following two mornings the alarm acted properly and sounded at the right
time. The third morning (which was today) I did not hear an alarm. I heard a
strange chime at 6 am (the same that indicates decide going offline), but
didn't get up to investigate. In the afternoon I looked at the N810 and saw
that it was online and had no indication whatsoever about any alarms that
should have sounded off at 10:30 am.
After an hour I left home, which meant my device went offline, and as soon as
it did, I heard the alarm mp3 sounding in my backpack. I pulled it out
intending to dismiss it, but found no sound and no alarm dialog. Could be I
pressed the touchscreen while pulling it out, but I usually lock the keyboard
before putting it in...
Anyway, 5 minutes later I was driving my car and I heard the alarm sound again.
I asked my passenger to shut it off.
So: alarm still unreliable, there's *some* strange connection with
online/offline modes, and the title of this bug is inaccurate.
The procedure to reproduce it seems to be "set up a daily alarm and wait a few
(In reply to comment #9)
> When I tap the screen to wake up the N810, I see the alarm dialog
> waiting to be dismissed.
Device has a so called "voip mode" which disables music while there's a voip
call in progress, but maybe that's somehow misbehaving. Could you install
syslog temporarily (see http://maemo.org/develoment/tools/) and check whether
/var/log/syslog has any relevant seeming messages (e.g. "forcing loudspeaker
OFF" from media-server) when this happens.
Are you using e.g. Skype and was that or some other VOIP application running in
the background? Or had you used one before this happened?
(I just got a comment that this happened after person had installed & used
Skype for the first time and before this alarms had worked fine for a long
>> Are you using e.g. Skype and was that or some other VOIP application running
>> in the background? Or had you used one before this happened?
-> moreinfo keyword (to whether this is int-94035)
Setting HIGH visibility to find more testers.
The summary is definitely not correct since alarms do work when the device is
offline and even shut down. Changing to "recurrent alarms" while we find the
Recurring alarms seem to work fine on my N800 running the latest Diablo; I've
had one running at 6:45am every morning for the last two weeks and it's gone
off every time. I've got SIP VOIP accounts setup that I've used numerous times
in between, and have had the tablet both in offline and online mode on
different days; the alarm worked regardless. I don't use Skype.
This bug still needs more testers, and exact steps to reproduce/information on
N800 or N810, and confirmation that you're running 5.2008.43.7.
Help highly welcome.
Difficult to say since there is not a clear way to reproduce this, but I have
been testing this with Fremantle and the alarms seem reliable.
I last tried to use the alarms about a month ago on my N810 with OS
5.2008.43-7. The first several days the alarm worked fine, then it started
popping up the alarm dialog at the right time but with no sound playing, making
the alarm pretty ineffectual. I know for a fact that the volume was not muted,
since I was listening to music every day during my daily commute.
Marius, would you like to try Comment #11 ?
Created an attachment (id=1201) [details]
syslog capturing the lack of an alarm sound at 10 am
Installed sysklogd. Set the alarm for 10 AM. Started media player. Played
some music. Closed the media player. Read some e-book in FBReader. Plugged
it into the charger. Next morning: alarm dialog pops up, but there's no sound.
The syslog is 350 kb. Interesting bits around 10 AM:
May 20 10:00:00 mg-n810-2 osso-media-server: sound resetetting pipeline
May 20 10:00:00 mg-n810-2 osso-media-server: forcing loudspeaker OFF
Skype is installed, but not running. I think Gizmo is installed too (but also
not running). The built-in IM client was offline.
I also find it interesting that the alarm tune (clock_alarm2.mp3) was mentioned
in the syslog when I was previewing it at 10 PM last night, but never after.
I'm attaching the syslog with irrelevant wlanconnd/icd2/udhcpc stuff stripped
out, gzipped, since it's still pretty big (why does alarmd care about wifi
I can confirm that the issue is not audio related. The command:
alarmtool -a --no-dialog --boot \
--exec "/etc/network/ics_connect.sh my_ssid" \
--time 1250510400 --recurr 1440 --recurr-count -1
was supposed to boot the device and run a script every day at the same time,
without sounding an alarm. It did not even boot. In my non-recurring tests,
it booted fine.
Also, the query option is completely broken. I've run "alarmtool -q" and
"alarmtool --query" many times after adding an event, and the output is always
"No events." I will submit a separate report if there isn't one already.
TESTED ON N800; OS ver. 5.2008.43-7
alarmd version: 0.5.20
alarmtool version: 0.5.18
libalarm version: 0.5.20
I see that alarmd executes under the "user" account, as opposed to root. Could
it be that alarmd is running into a permissions issue in some cases?
As an experiment, I tried running "/usr/bin/alarmd -d" as root, and killing the
current (user owned) alarmd. But alarmd is immediately rerun under the user
account, even if it's already running under the root account.
Bug 4935 makes it difficult to diagnose the bug herein, because alarmtool will
not show the queue of events. Is there another way to get the event queue?
(In reply to comment #21)
> I see that alarmd executes under the "user" account, as opposed to root. Could
> it be that alarmd is running into a permissions issue in some cases?
> As an experiment, I tried running "/usr/bin/alarmd -d" as root, and killing the
> current (user owned) alarmd. But alarmd is immediately rerun under the user
> account, even if it's already running under the root account.
> Bug 4935 makes it difficult to diagnose the bug herein, because alarmtool will
> not show the queue of events. Is there another way to get the event queue?
You can check the alarm event queue directly by reading the XML file:
You can also try polling the active alarmD daemon by sending it dbus requests
using dbus-send; just look up the alarmD API for possible options, though this
isn't nearly as easy to understand as just looking at the queue file since API
is a bit limited and usually needs a few calls in order to make sense or
If we need a standalone app to check alarmD events/config with I'm not sure
what the deal with alarmtool is but I can probably build up something quick,
I've used alarmD extensively from Python in FlipClock, and am right in the
middle of a C-based app that will do the same thing so should be pretty easy.
My guess though is that all the problems people are reporting here have more to
do with some goof in AlarmD actually presenting events (i.e. the part of AlarmD
that's responsible for basic MP3 playback, screen waking, etc) rather than the
real scheduling daemon, as I've been using it with FlipClock for about 4 months
now (with recurring alarms each day of the week) and never once had an issue
with an alarm being triggered...
In response to Rob, I believe my test results rule out the theory that this
problem is at the presentation level. I have scheduled an event that has no
dialog, whistles or bells, and simply kicks off a script. It works as a
one-off event, but it fails when it's scheduled as a recurring event.
More test results:
alarmd internally uses retutime to wake the device up. So I have bypassed
alarmd to schedule power on events directly with retutime, and it has succeeded
2 out of 5 times.
The test was performed by setting the device to wake up in 4 minutes, as
$ let AMIN=$(/usr/sbin/chroot /mnt/initfs /usr/bin/retutime --get-time \
| sed -e 's@[^:]*:\([^:]*\):.*@\1@')+4
$ ATIME="$(/usr/sbin/chroot /mnt/initfs /usr/bin/retutime --get-time \
| sed -e 's@\([^:]*:\).*@\1@')$AMIN:00"
$ /usr/sbin/chroot /mnt/initfs /usr/bin/retutime --set-alarm $ATIME
(note: don't try this during the last 4 minutes of the hour because the
arithmetic above doesn't do modulo arithmetic)
Interesting about the Retutime thing... just to clarify on this, are we talking
about recurring alarms that are meant to wake the device, or all recurring
alarms?... Obviously the tests with Retu time are demonstrating that pulling
the device out of power down is having some problems with consistency; that
being established can we conclude that this is the only problem? Or are there
times when other recurring alarms have been set with the device still powered
up that fail for people?
That's a good point Rob. The retutime failure may be a different problem
entirely -- or it's also possible that the problems with recurrence are a side
effect of the retutime issue.
In any case, it's a different scenario (problems with non-recurring wakeups) so
I've created bug 5117 for retutime.
So can someone please update the status here by testing this in Maemo5 on the
I'm using a daily recurring 7 AM alarm on my N900 for three weeks now. No
fwiw I'm waking up with the N900 for about 3 months without any issues.
Some mornings there were no alarms, but it was me forgetting to backup/setup
alarm after flashing the device. ;)
I can also confirm that recurrent alarms seem to work just fine on my N900.
Resolving as FIXED in Fremantle (and WONTFIX in previous versions, if anybody
still has this problem).