Cirrocumulus
Has anyone else ever had problems with RULE_INIT not firing for some iRules?
I have a 10.1.0 6400 and when editing an iRule with the iRule editor, I get an error from mcpd on saving it (The save works though), saying that the rule already exists in partition common, and the RULE_INIT event doesn't trigger...
H
Cirrocumulus
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
Altostratus
Cirrostratus
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.
Cirrostratus
Thanks,
Aaron
