Service name and pattern handling is not backward compatible

[Lutz Mader]

Hello Tildeslash,
nice to see monit support a name or pattern for the service name,
unfortunately the name is case sensitive, now.

# monit -B summary postgres
Service 'postgres' not found

# monit -B summary Postgres
Monit 5.28.0 uptime: 36m
 Service Name                     Status                      Type
 Postgres                         Not monitored               Process

# monit -B summary postgres
Monit 5.27.2 uptime: 2d 12h 39m
 Service Name                     Status                      Type
 Postgres                         Not monitored               Process
#

Sorry, some people like pattern but case insensitivity was nice too.

To the comment (see src/http/cervlet.c)

// 2) backard compatibility: before monit 5.28.0 there was no support for
regular expresion => check verbatim match before trying regex (the service
may contain special characters)

the behavior is unfortunately not backward compatible.

With regards,
Lutz

p.s.
See https://bitbucket.org/tildeslash/monit/issues/915/feature-request-monit-command-with-regex

A pattern is not very useful sometimes, but seems to work, I like it.

# monit -B summary '[Pp]ostgres'
Monit 5.28.0 uptime: 2h 33m
 Service Name                     Status                      Type
 Postgres                         OK                          Process
#

‌

[Tildeslash]

Thanks for report Lutz.

I actually wasn’t aware that the service name was case-insensitive, this behaviour was never documented if i remember correctly. But as it used IS → Str_isEqual for name comparison, it was case-insensitive indeed, although it is kind of bug.

The fallback code in the new implementation is also case insensitive, but your test pattern probably compiled fine by regcomp(), so it didn’t use the fallback.

It would be possible to make the new implementation case-insensitive easily by adding REG_ICASE option to regcomp() … as nobody complaint so far, it probably wouldn’t be problem => will add it and document the case-insensitivity.

[Tildeslash]

Fixed: Issue #966: Service name pattern for CLI commands was case-sensitive in 5.28.0. This case-insensitive feature was never documented and i think it was kind of mistake, which became a feature. The parser is also case-insensitive when it checks for duplicate service names, and as nobody complaint so far about the case-sensitivity, it probably never was a problem => make the regex case-insensitive and document case-insensitivity

→ <<cset 5c3a699513dd>>

[Lutz Mader]

Hello,
thanks for fixing.
I think, this is the way how monit handle service names and keywords.

This case-insensitive feature was never documented and I think it was kind of mistake, which became a feature.

You can not define two services with a similar name.

check filesystem Case_Test with path /dev/disk0s2
check filesystem case_test with path /dev/disk0s4

Service name conflict, case_test already defined '/dev/disk0s4'

There is no hint to the used notation of the service names, on the other hand you can use the keywords in any notation also. The keywords are case insensitive.

Snipped from the manual.

Each service entry consists of the keywords check, followed by the service type. Each entry requires a unique descriptive name, which may be freely chosen. This name is used by Monit to refer to the service internally and in all interactions
with the user.

All compares I find are based on macro "IS" (from src/monit.h) and/or "Str_isEqual". And "Str_isEqual" (from libmonit/src/util/Str.c, with "toupper") compare normalized to uppercase strings only.

So what, the old behavior is back again,
thanks for your explanation,
Lutz

p.s.
The config file syntax used by "fetchmail" is the base of the used syntax, this will give a hint to a very robust and funny syntax parser.
Snipped from the manual.

The syntax (and parser) of the control file was inspired by Eric S. Raymond et al.'s excellent fetchmail program.

I like parser are able to handle readable configuration files or use easy to handle files based on ASN.1 (or on BNF).