What are Pseudo-Events and why are they used?

By Elevate posted 08-10-2015 21:41


Prior to Junos OS Release 8.3, not all syslog messages were combined in eventd and we were not able to write event-policy for all the syslog messages. With Junos OS Relase 8.3 and later, after merging syslogd and eventd into one process, all the syslog messages are routed to eventd. However, not all the syslog messages have a proper event-id, and changing all the existing syslog messages to have proper event-ids is not possible.


So, for all syslog messages that do not have a proper event-id, eventd groups them under pseudo-events based on the origin of the messages.


The following pseudo-event-ids are assigned:


Pseudo Event ID                                            Description
SYSTEM For messages coming from other Junos OS daemons and utility programs that do not use the ERRMSG() macro.
KERNEL For messages coming from kernel.
PIC For messages coming from pics (for example, ggsn pics).
PFE For messages coming from PFE
LCC For messages coming from LCC.
SCC For messages coming from SCC.


Each of these pseudo-event-ids has a special attribute named 'message'. The  value of the attribute will be the syslog message. Using this pseduo-event-id and its attribute, we can write policy to match any syslog messages that do not have a proper event-id. For example, to generate an event policy to capture a daemon crash, whenever any daemon crashes, "init" generates a message like the following:



Feb 09 05:07:34.643 2012 candyman init: routing (PID 4016) terminated by signal number 11. Core dumped!


This means that the routing process has generated a core dump because of signal 11. We can use this error message to find out the daemon crash. 


The init process does not use the ERRMSG() macro to send messages to eventd.


So, there is no proper event-id for this message.


We can write an event-policy using the pseudo-event-id, something like the following:


1 policy daemon-crash {
2     events SYSTEM;
3     attributes-match {
4         SYSTEM.message matches ".*terminated by signal number.*";
5     }
6     then {
7         event-script daemon-crash.slax {
8             arguments {
9                 message "{$$.message}";
10             }
11             output-filename test;
12             destination foo;
13         }
14     }
15 }


This policy will match for pseudo-event SYSTEM and the line matching the above regular expression. As an action, the policy event-script will get executed and the error message will be passed as an argument to the event-script.


Within the event-script, using the error message argument we can figure out the daemon name and the signal number.

Something like the following:


1 param $message;
2 match / {
3     var $ret = jcs:regex("([a-zA-z]+) .* ([0-9]+)", $message);
4 }


Here $ret[2] will be "daemon name" and $ret[3] will be "signal number".