Active Topics

 



Notices


Reply
Thread Tools
Posts: 67 | Thanked: 13 times | Joined on Feb 2008 @ U.S.A.
#1
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?
 
Posts: 81 | Thanked: 115 times | Joined on Jan 2008
#2
get alarmtool from here:
http://repository.maemo.org/pool/dia...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
 

The Following 5 Users Say Thank You to iKneaDough For This Useful Post:
Posts: 67 | Thanked: 13 times | Joined on Feb 2008 @ U.S.A.
#3
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:
Code:
-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's Avatar
Posts: 2,669 | Thanked: 2,555 times | Joined on Apr 2007
#4
You want to use cron instead.
 
Posts: 67 | Thanked: 13 times | Joined on Feb 2008 @ U.S.A.
#5
Originally Posted by zerojay View Post
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:
Code:
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:
Code:
#!/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
 

The Following 6 Users Say Thank You to jgombos For This Useful Post:
Posts: 67 | Thanked: 13 times | Joined on Feb 2008 @ U.S.A.
#6
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

Last edited by jgombos; 2009-08-17 at 13:52.
 
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#7
Originally Posted by jgombos View Post
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.
 
Posts: 67 | Thanked: 13 times | Joined on Feb 2008 @ U.S.A.
#8
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.

Last edited by jgombos; 2009-08-17 at 17:40.
 
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#9
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/dia..._0.5.20.tar.gz (look at rpc-retutime.c)
 

The Following User Says Thank You to qwerty12 For This Useful Post:
Posts: 67 | Thanked: 13 times | Joined on Feb 2008 @ U.S.A.
#10
Originally Posted by qwerty12 View Post
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:
Code:
# 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:
Code:
# 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:
Code:
$ 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.

Last edited by jgombos; 2009-09-05 at 20:08.
 
Reply


 
Forum Jump


All times are GMT. The time now is 17:40.