Permanently lit SMART trigger status is not OK

[AntonAndreevichMoroz]

Trigger SMART status is not OK constantly in the Problem state for all disks.

[AntonAndreevichMoroz]

But in fact, all results get PASSED. Why does the trigger fire?

[v-zhuravlev]

please show me trigger expression and what is the value that you have?

[AntonAndreevichMoroz]

In the template, such a trigger {PC-004-77-01004:uHDD.health["/dev/sda -data"].count(#1,{$SMARTCTL_OK_STATUS:"SATA"},ne)}=1 and {PC-004-77-01004:uHDD.health["/dev/sda -data"].count(#1,{$SMARTCTL_OK_STATUS:"SAS"},ne)}=1

In a specific problem, it is revealed in this form {PC-004-77-01004:uHDD.health["/dev/sda -data"].count(#1,PASSED,ne)}=1 and {PC-004-77-01004:uHDD.health["/dev/sda -data"].count(#1,OK,ne)}=1

The latest data comes in and shows the normal state of the disk. /dev/sda: Test result | 31.05.2019 11:45:56 | PASSED

[v-zhuravlev]

Is host Windows or Linux?

[v-zhuravlev]

My guess is that there is a whitespace character in the output. Try changing regex in preprocessing step for something like this? (?:SMART overall-health self-assessment test result:|SMART Health Status:) +\b([\S ]+) or if this doesn't help. maybe even this: (?:SMART overall-health self-assessment test result:|SMART Health Status:) +\b([\w ]+)

[AntonAndreevichMoroz]

Windows client. I eventually made these conditions for the trigger. Unfortunately, I don’t know how to imitate 100% of a poor SMART state, but changing the text in a macro gives the correct triggering effect. Please give your expert opinion how much it is correct. Thank you in advance. {Template_HDD_SMARTMONTOOLS_2_WITH_LLD:uSSD.health["{#DISKCMD}"].iregexp({$SMARTCTL_OK_STATUS:"SATA"},#1)}=0 and {Template_HDD_SMARTMONTOOLS_2_WITH_LLD:uSSD.health["{#DISKCMD}"].iregexp({$SMARTCTL_OK_STATUS:"SAS"},#1)}=0

[v-zhuravlev]

Can you try to revert trigger expression back and use the line I suggested in this item preprocessing? (?:SMART overall-health self-assessment test result:|SMART Health Status:) +\b([\S ]+)

[gijoe88]

The new regexp (with \S) solved the issue for me. I don't think it was linked to there being a space in the result, but to "line endings" of windows having "\r\n", the \r being caught by "." of regex when on unix server.