How to schedule scripts (using alarmd?)

[jgombos]

I need a script to run daily at a particular time.

/etc/crontab would normally be the approach, but there is no cron tool (despite existence of /etc/cron.daily).

Documentation seems to suggest "alarmd" for this. The manual at http://maemo.org/api_refs/4.0/alarm-api/index.html is really just C code documentation. Where's the user documentation?

If I simply want to run do_something.sh at 1am every day, for example, what's the procedure?

[iKneaDough]

get alarmtool from here:
http://repository.maemo.org/pool/diablo/free/a/alarmd/alarmtool_0.5.20_armel.deb

the manpage that comes with that package:

NAME
alarmtool - tool to test event daemon functionality

SYNOPSIS
alarmtool [OPTION]...

DESCRIPTION
alarmtool provides means to add different alarm events to queue of alarmd.

OPTIONS
-a, --add
Adds an event to the queue, see section ADDING EVENTS.

-r eventid, --remove eventid
Removes event from the queue. The id supplied should be as got from adding or querying events.

-q, --query
Queries events on the queue, see section QUERYING EVENTS.

-g eventid, --get eventid
Gets info about an event. The id supplied should be as got from adding or querying events.

ADDING EVENTS
When adding events, you need to specify certain details about the event. On successful addition, the id of the added event is printed to standard output. The details of the event should be set with following flags:

-t time, --time time
The time the event should launch, in seconds since epoch.

-R interval, --recurr interval
The time interval between two successive runs of the event in minutes. Default is no repeating.

-C n, --recurr-count n
How many times should the event be repeated, -1 for infinite.

-i iface, --dbus-interface iface
Interface for dbus action of the event.

-s service, --dbus-service service
Service to be called via DBus. If this is specified, dbus action will be a method call.

-p path, --dbus-path path
Path for dbus action of the event.

-n name, --dbus-name name
Name of dbus method/signal.

-y, --dbus-system-bus
If used, the dbus action will be done over system bus, otherwise session bus is used.

-m message, --dialog-message message
Message to show in the alarm dialog.

-c icon, --dialog-icon icon
Icon name or path to show in the alarm dialog.

-u sound, --dialog-sound sound
Path to a sound file to play when the alarm dialog is shown.

-e command, --exec command
Command to execute when the event is run. (You can only have DBus or exec, not both).

-d, --no-dialog
If used, the event will not show a dialog when run.

-z, --no-snooze
If used, the snooze button in events alarm dialog is disabled.

-o, --boot
If used, the event will wake the device if powered off.

-b, --show-icon
If used, a alarm indicator will be shown in statusbar for the lifetime of the event.

-r, --run-delayed
If used, the event will be run even if the time was missed due to powered off device, or jumping over the set time. Otherwise the event will be removed silently.

-w, --connected
If used, the event will be launched only when there is an internet connection. If no connection is available at that time,

-a, --activation
If used, the dbus method call will use activation flag.

-P, --postpone-delayed
If used, the event will be moved forward to next day, if it is delayed for more than one day.

-B, --back-reschedule
If used, a recurring alarm will be forced to be within recurr interval from current time, and thus can be moved backwards, if device time is changed. alarmd will wait for a connection and launch the event then.

QUERYING EVENTS
The events on the queue can be queried based on their time and flags. The list of ids for the events is printed to standard output. The default for flags is not to care about them. If a flag and its negative are both specified, the last one is used. The details to query are set using following flags:

-f time, --first-time time
Query events set to time greater than this. In seconds since epoch.

-l time, --last-time time
Query events set to time less than this. In seconds since epoch.

-Y, --dbus-session-bus
Query events that use session bus for dbus actions.

-y, --dbus-system-bus
Query events that use system bus for dbus actions.

-D, --dialog
Query events that use the alarm dialog.

-d, --no-dialog
Query events that do not use the alarm dialog.

-Z, --snooze
Query events that allow snooze in the alarm dialog.

-z, --no-snooze
Query events that do not allow snooze in the alarm dialog.

-o, --boot
Query events that power the device on, if powered off.

-O, --no-boot
Query events that power the device on, if powered off.

-b, --show-icon
Query events that show icon in the status bar.

-B, --no-show-icon
Query events that do not show icon in the status bar.

-r, --run-delayed
Query events that are run afterwards if missed due to power off or time change.

-R, --no-run-delayed
Query events that are not run afterwards if missed due to power off or time change.

-c, --connected
Query events that require an internet connection to be run.

-C, --no-connected
Query events that do net require an internet connection to be run.

-a, --activation
Query events that use DBus activation.

-A, --no-activation
Query events that do not use DBus activation.

-p, --postpone-delayed
Query events that are postponed if missed.

-P, --no-postpne-dlayed
Query events that are not postponed if missed.

-e, --back-reschedule
Query events that are moved backwards if time is changed backwards.

-E, --no-back-reschedule
Query events that are not moved backwards if time is changed backwards.

RETURN VALUE
If an action was successful, the return value will be 0. If there was error in input 1 is returned, and if an event specified could not be found, -1.

SEE ALSO
alarmd(8)

HISTORY
Oct 3 2006: Initial version of this manual page.

COPYRIGHT
Copyright © 2006 Nokia Corporation.

This is free software; see /usr/share/common-licenses/LGPL-2.1 for license conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Nokia

[jgombos]

Thank you!

It works pretty well.

The query option doesn't work, however. I always returns "No events" even when there are.

There's also a copy/paste typo in the man page:

-o, --boot
Query events that power the device on, if powered off.

-O, --no-boot
Query events that power the device on, if powered off.

[zerojay]

You want to use cron instead.

[jgombos]

You want to use cron instead.
Why?

I read somewhere that cron isn't offered on the NIT, because it's too heavy (although I'm not sure why I see a /etc/cron.daily folder).

Theoretically, alarmtool does what I need. I have a script set up to boot every morning (Eg. 12pm GMT), connect to the LAN, and download news for offline reading, using a command like:

alarmtool -a --no-dialog --boot \
--exec "/etc/network/ics_connect.sh my_ssid" \
--time 1250510400 --recurr 1440 --recurr-count -1

Are there any issues I should anticipate? I ran it as a test without the recurring options, and it worked.

BTW, if anyone wants to do the same, the script to connect to the LAN ("ics_connect.sh") looks like this:

#!/bin/sh

source /etc/osso-af-init/af-defines.sh

NET_NAME=$1

# The NET_ID can be seen by running:
#
# gconftool-2 -R /system/osso/connectivity/IAP \
# | grep -B 25 ssid

NET_ID="$(gconftool-2 -R /system/osso/connectivity/IAP \
| sed -ne '/\/system\/osso\/connectivity\/IAP\//,
/^ *name = /
s@.*/IAP/\([^:]*\):@\1@gp;
s/^ *name = \(.*\)/\1/gp' \
| sed -ne \
'/-.*-.*-.*-/{;N;s/\(.*\)\n'${NET_NAME}'/\1/gp;}')"

echo "Network name is $NET_NAME and network id is $NET_ID"

# Switch back to online mode and reconnect to the default
# access point
#
/usr/bin/dbus-send --system --type=signal \
/com/nokia/mce/signal \
com.nokia.mce.signal.sig_device_mode_ind \
string:"normal"

echo "connecting to \"$NET_ID\""

/usr/bin/dbus-send --system --print-reply \
--type=method_call \
--dest=com.nokia.icd \
/com/nokia/icd com.nokia.icd.connect \
string:"$NET_ID" uint32:0

[jgombos]

Looks like alarmtool failed. It worked when I scheduled a one-off boot and connect to execute a few minutes later, but when I told it to boot the next morning, every morning thereafter, it simply did not execute.

Is this why cron was suggested?

According to GA ( http://talk.maemo.org/showthread.php?t=25686 ) cron was withheld from the distro because it's a battery killer. Apparently those not concerned w/ battery life can install it ( http://talk.maemo.org/showthread.php?t=12572 ).

I'm thinking cron won't work for this purpose. If it's a battery killer, it most likely cannot boot the device from a powered off state, like alarmtool can.

[EDIT] A bug report exists for broken recurring alarms: https://bugs.maemo.org/show_bug.cgi?id=1112

[lma]

According to GA ( http://talk.maemo.org/showthread.php?t=25686 ) cron was withheld from the distro because it's a battery killer.

A well-behaved crond may be slightly more wasteful than an alarm API, but hardly a battery killer. When it doesn't have scheduled work to do It should just wake up once a minute, stat(2) the crontab(s) and go back to sleep.

[jgombos]

Since alarmd is broken, I will probably switch to cron.

The bummer is that I'll have to leave the device on all night, because cron can't boot the device, from what I hear.

Since alarmd is only known to be broken on recurring events, I might try submitting a non-recurring event that runs a script that reschedules itself.

[qwerty12]

alarmd* uses retutime in initfs (sudo gainroot and chroot /mnt/initfs/ retutime) to set the time for the device to wake up. No idea if this would have to keep being set everytime it has woken up but your script could handle that.

* http://repository.maemo.org/pool/diablo/free/a/alarmd/alarmd_0.5.20.tar.gz (look at rpc-retutime.c)

[jgombos]

alarmd* uses retutime in initfs (sudo gainroot and chroot /mnt/initfs/ retutime) to set the time for the device to wake up. No idea if this would have to keep being set everytime it has woken up but your script could handle that.

Looking at the manpage, there is no way to hook an alarm event to an action:

# retutime -h
retutime, Version 1.0.8
Copyright (C) 2004-2005 Nokia Corporation
All rights reserved.

Usage:
-T, --set-time Set date string (in UTC)
(Y-m-d/H:M:00 -- ex. 2004-11-12/13:16:11)
-t, --get-time Get date string
(Y-m-d/H:M:S -- ex. 2004-11-12/13:16:45)
-A, --set-alarm Set alarm string (In UTC; seconds don't count
and date must be within 24 hours from current time)
(Y-m-d/H:M:00 -- ex. 2004-11-12/13:16:00)
-a, --get-alarm Get alarm time
-S, --clear-alarm-status Acknowledge the alarm
-s, --get-alarm-status Get alarm expiration status
-R, --clear-reset-status Acknowledge the reset
-r, --get-reset-status Get reset status
-C, --set-calibration Set calibration data
-c, --get-calibration Get calibration data
-I, --rtc-from-system Set RTC to match system time
-i, --system-from-rtc Set system time to match RTC
-h, --help Show usage

Report bugs to Bugzilla.

The C code doesn't show a way to do this either. So presumably retutime is strictly to power on the device, correct?

I did some experimenting:

# retutime --get-time
2009-09-05/17:42:23
# retutime --set-alarm 2009-09-05/17:44:00
# retutime --get-alarm
2009-09-05/17:44:00
# retutime --get-alarm
Alarm off
# retutime --get-alarm-status
1

When the alarm time hit, nothing happened. No power on; and when it's already powered on, no dialog or audibles. However, the "alarm off" response to "retutime --get-alarm" suggests that the alarm was unscheduled, as if an event had executed.

So it seems the defect is not with the alarmd daemon, but rather at a lower level, in retutime.

[EDIT]
Did some more testing. Sometimes retutime powers the device on, and sometimes it doesn't.

If anyone wants to see for themselves, these are the commands to run:

$ 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

$ poweroff

Those commands will schedule a power on 4 minutes later, and power the device off. It works about half the time.

It seems to work less the shorter the time, but then my sample size is only about 8 or so.