RULE_INIT not firing

Apologies for the duplicate (Grrr... Firefox)... I can't delete the other one...

 

 

Anyway... What I've found is that if you ever get a TCL error in RULE_INIT, then RULE_INIT event won't fire again, until you delete and re-create the iRule. Even on a 'b load' it won't fire.

 

 

I didn't expect that... It means if you EVER mistype something in RULE_INIT (Like I did) you have to delete the iRulebefore you can get it to initialise again.

 

 

H

Wow, good catch Hamish.

What kind of TCL error did you see get to cause the problem? I just tested a simple rule like this, but didn't see a problem:

 
 when RULE_INIT { 
  
    log local0. "\[clock seconds\]: [clock seconds]" 
  
     Bad "command" 
    test    
 } 
 

Added a log statement to RULE_INIT

Jan 14 16:31:03 local/tmm info tmm[8462]: Rule rule_init_rule : [clock seconds]: 1263486663

Jan 14 16:31:03 local/tmm1 info tmm1[8463]: Rule rule_init_rule : [clock seconds]: 1263486663

Added a bad command "test" after the log statement

Jan 14 16:31:13 local/test-3600-2 err mcpd[3462]: 01020066:3: The requested rule (rule_init_rule) already exists in partition Common.

Jan 14 16:31:13 local/test-3600-2 err mcpd[3462]: 01070151:3: Rule [rule_init_rule] error: line 4: [undefined procedure: test] [test]

Removed the bad command "test" after the log statement

Jan 14 16:32:03 local/test-3600-2 err mcpd[3462]: 01020066:3: The requested rule (rule_init_rule) already exists in partition Common.

Jan 14 16:32:04 local/tmm info tmm[8462]: Rule rule_init_rule : [clock seconds]: 1263486724

Jan 14 16:32:04 local/tmm1 info tmm1[8463]: Rule rule_init_rule : [clock seconds]: 1263486724

Aaron

Posted By Hamish on 01/14/2010 4:55 AM

 

Anyway... What I've found is that if you ever get a TCL error in RULE_INIT, then RULE_INIT event won't fire again, until you delete and re-create the iRule. Even on a 'b load' it won't fire.

 

 

 

 

Yes, this is CR133851. The workaround for this CR is to make "after 1" be the first command in RULE_INIT. This is specifically a workaround for that CR, and should not be considered a "best practice". It won't make things start working if they're in a non-working state, but it will prevent them from breaking again. You could, as you found, delete the rule and recreate it.

 

 

A closely related issue that several customers have also run into is that sometimes iRules get processed before classes which can lead to RULE_INIT failure (this is CR132122). This can happen when tmm gets restarted but mcpd does not. This fix is already in our next release, and will eventually be in 10.0.1 and 10.1.0 rollup hotfixes.

 

 

The big mess happens when you run into the second CR, which causes the problem, and then the first CR, which means you can't easily fix it. These CRs only seem to be happening on v10.x systems, although the code has been the same for a very long time, so they should affect other versions in theory.

 

Out of curiosity, what type of TCL error triggers the issue? I tried searching for CR133851 and CR132122 but didn't find anything published.

 

 

Thanks,

 

Aaron

Any error that mcpd can't catch. In your example, mcpd noticed that the iRule called an undefined procedure, so it caught the error.