Menu

Main Menu
Talk Get Daily Search

Member's Online

    User Name
    Password

    How to schedule scripts (using alarmd?)

    Reply
    jgombos | # 1 | 2009-08-16, 15:35 | Report

    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?

    Edit | Forward | Quote | Quick Reply | Thanks

     
    iKneaDough | # 2 | 2009-08-16, 16:43 | Report

    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

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 5 Users Say Thank You to iKneaDough For This Useful Post:
    codeMonkey, Jaffa, jgombos, qole, timsamoff

     
    jgombos | # 3 | 2009-08-16, 19:44 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    zerojay | # 4 | 2009-08-16, 19:50 | Report

    You want to use cron instead.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    jgombos | # 5 | 2009-08-16, 20:12 | Report

    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

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 6 Users Say Thank You to jgombos For This Useful Post:
    gogol, Jaffa, lma, qole, qwerty12, timsamoff

     
    jgombos | # 6 | 2009-08-17, 06:50 | Report

    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

    Edit | Forward | Quote | Quick Reply | Thanks

    Last edited by jgombos; 2009-08-17 at 13:52.

     
    lma | # 7 | 2009-08-17, 08:00 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    jgombos | # 8 | 2009-08-17, 17:30 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks

    Last edited by jgombos; 2009-08-17 at 17:40.

     
    qwerty12 | # 9 | 2009-08-17, 17:45 | Report

    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)

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to qwerty12 For This Useful Post:
    jgombos

     
    jgombos | # 10 | 2009-09-05, 17:53 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks

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

     
vBulletin® Version 3.8.8
Normal Logout