Checking the status of an EEM timer

[benstrauss]

Given an event manager applet set to trigger with an "event timer countdown" or "event timer watchdog" statement, is there any way of viewing the current timer status (i.e. remaining time until trigger)?

[Joe Clarke]

No, there is no show command which will tell you exactly the time remaining. However, if you run "show event manager policy registered", look at the time registered, you can calculate the amount of time remaining by comparing that with the output of "show clock". You could even write an EEM policy to do it for you :-).

[benstrauss]

Unfortunately that approach is of marginal usefulness, for a couple of reasons:

(a) If the router has been reloaded since the applet was added, the registration time may show up in terms of the clock's time immediately after reboot, but before the clock is resynced. In the case of one router I just tried it on, an 871, all of the applets show up as being registered on Feb 28, 2002 18:00 local time. Surely enough, this meshes with what is seen in the console output when it is reloaded. Prior to the %SYS-5-RESTART message, the router thinks it's Mar 1 2002 00:00 UTC:

*Mar 1 00:00:46.547: %HA_EM-4-FMPD_NO_EVENT: No event configured for applet backhaul

*Mar 1 00:00:47.847: %SYS-5-CONFIG_I: Configured from memory by console

*Oct 22 19:17:23.631: %SYS-5-RESTART: System restarted --

Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)

This does not seem to be the case on all routers, for instance the 2800 series, but it cannot be relied on.

(b) Even if the registration time were reliable, it would only be immediately useful in the case of a countdown timer. As it is, I have a watchdog timer running every 27 minutes (I have a reason for this.) Knowing only the registration time would require parsing the registration time string and computing the number of 27 minute periods elapsed. (Okay, it could be computed by an applet, but this would be rather messy.)

So basically, they forgot a very basic "show" command. I assume that an appropriate command will eventually be added.

[Joe Clarke]

Yes, the first problem is the most critical. The second one can be accomplished with a programmatic applet or Tcl.

I have not heard of plans to implement such a show command, but I do see the use of it (perhaps an enhancement to show event manager policy registered).

[benstrauss]

Such a computational applet could be a mess, as the "show event manager policy registered" gives the registration time in local time and does not indicate whether daylight time was in effect at the time.

[Joe Clarke]

I don't think it needs to be that complicated. You don't really care about DST for a watchdog or countdown timer. It's going to countdown no matter what the clock is set to. The attached policy should give you a rough estimate of the time left. Just set the "show_timer_name" environment variable to the name of a watchdog or timer policy, then run:

event manager run no_show_timer.tcl

[Joe Clarke]

Here's an improved version which should workaround problem one with regard to NTP clock sync. This version checks the output of "show event manager history events" to get the last time a policy fired (if it's still in the history). While still not perfect, it's much less rough than the first version.

[Joe Clarke]

One more time. This version fixes a bug with countdown timers.

[benstrauss]

Thanks.

Although it needed a few little tweaks, it makes a viable proof of concept.

One of the nice things about using tcl for this is that the "clock scan" command takes care of the clock parsing and takes into account daylight time automatically.

A couple of things, though. The use of the last fire time, based on the event history, assumes that the time hasn't been modified since then - which would not only reset the timer, but also the registration time. I would propose only using the last fire time if it is later than the registration time.

Also, the problem remains, though, with repect to certain models, such as the 871, where, after a reboot, the registration time on existing applets/policies winds up reverting to Mar 1 2002 00:00 UTC.

Of course, all of this could be avoided if there were just some way of accessing the actual timer values.

By the way, I do notice that one of the options available when creating a timer is to specify a name for the timer itself, apart from the name of the applet or policy (e.g. in an applet, "event timer countdown time 600 name timerName"). Apart from this name showing up in "show event manager policy registered" output (which incidentally, requires a tweak in your script), I assume that this naming ability has no function, such as being able to reference the timer.

[Joe Clarke]

What tweaks were required? I tired to accommodate all changes to the show event manager policy registered output.

As for handing the case of the bogus registration time, that was why I went to using the history time (if available). The odds of this being bogus are much less.

The name of the timer can be used for timer subscriber policies. Typically, though, one registers a timer using the register_timer command if one wants to create a timer subscriber.

[benstrauss]

The couple of minor tweaks I needed to throw in were as follows:

(a) If the timer had no event history entries, that is the filtered output from "show event manager history events" returned nothing, the run_cli output returned in the $output variable would still contain a copy of the router command prompt (e.g. "routername#"). The trailing prompt is included in the cli_exec output regardless of whether there is any other output. In any case, the workaround was to change the subsequent "if { [llength $lines] > 0 }" to "if { [llength $lines] > 1 }"

(b) If the aforementioned timer name option is used, the output from the "show event manager policy registered" command is slightly different. Instead of just "timer 600.00", the output line might read "name {timerName} time 600.000", thus the regular expression which refers to "^time" needed to be altered to accomodate the fact the the time might not be at the beginning of the line.

My point regarding the state of affairs after a reload is based on the fact that you can't make use of event history immediately after a reload, as the history does not survive a reload. Thus, there is no definitive way of determining a start time for the timers' first firing unless you rely on the potentially unreliable registration time or, perhaps, the router reload time.

The use of event history also assumes that the maximum allowed limit of 50 history entries has not been exceeded since the last firing. This may not be a valid assumption if many other, perhaps minor, events have taken place during a days-long countdown.

[Joe Clarke]

Ah, thanks for the pointers. Yes, I tested without timer names. I had added code to filter out the device prompt. Checking for llength $lines > 1 is fine, but it's not needed. The follow while block will skip lines which don't match the policy name.

You are correct, the first time you run the policy after a reload, the registration time must be used. If that is bogus, then the first output of remaining time will also be bogus.

Yep, I'm aware that history is not perfect. As I said, this is mainly a rough workaround. The real fix will be to add a show command which plugs into the EEM API directly.

[Joe Clarke]

I filed CSCtc79470 requesting the new feature.

[benstrauss]

Actually I found the $lines>1 change to be necessary, as without it, if there was no history for the policy or applet (as is the case after a reload or for a newly created timer-based policy or applet), the script would time out attempting to digest the CLI output:

Process Forced Exit- MAXRUN timer expired.

while executing

"regexp "$show_timer_name" $line"

invoked from within

"$slave eval $Contents"

(procedure "eval_script" line 7)

invoked from within

"eval_script slave $scriptname"

invoked from within

"if {$security_level == 1} { #untrusted script

interp create -safe slave

interp share {} stdin slave

interp share {} stdout slave

..."

(file "tmpsys:/lib/tcl/base.tcl" line 50)

Tcl policy execute failed: Process Forced Exit- MAXRUN timer expired.

[Joe Clarke]

Ah, right, of course. It would result in an infinite loop. I will correct it. Thanks.