Oracle plugin sql check crashing after upgrade to checkmk 2.4

Troubleshooting
1

CMK version: 2.4.36 community
OS version: Oracle Linux 8.10

Error message: see below

Hi,

After upgrading checkmk community from 2.3.47 to 2.4.36 some check started crashing.

It’s the oracle_sql check in the oracle plugin “mk_oracle” that crashes. The section where you can have your own sql queries.

I have 3 different checks that use this section. All of them crash.

When I run the agent locally, the output is fine. Also when I run the agent output on the checkmk gui, I get the output correctly. But the service shows that it has crashed. I haven’t changed anything in the sql query or config. Agents upgraded to 2.4.36 dont’t work, neither do the ones that have the old 2.3 version.

The crash report says the following

Exception:
ValueError ('notice' must be non-empty str or None, got )

Traceback:

File "/omd/sites/sysco_prod01/lib/python3/cmk/base/checkers.py", line 912, in get_aggregated_result
check_result = check_function(**item_kw, **params_kw, **section_kws)
File "/omd/sites/sysco_prod01/lib/python3/cmk/base/checkers.py", line 685, in __check_function
return _aggregate_results(consume_check_results(check_function(*args, **kw)))
File "/omd/sites/sysco_prod01/lib/python3/cmk/base/checkers.py", line 757, in consume_check_results
for subr in subresults:
File "/omd/sites/sysco_prod01/lib/python3/cmk/base/api/agent_based/register/check_plugins.py", line 96, in filtered_generator
for element in generator(*args, **kwargs):
File "/omd/sites/sysco_prod01/lib/python3/cmk/plugins/oracle/agent_based/oracle_sql.py", line 184, in check_oracle_sql
yield Result(state=State.OK, notice="\n".join(long))
File "/omd/sites/sysco_prod01/lib/python3.12/site-packages/cmk/agent_based/v1/_checking_classes.py", line 408, in new
state, summary, details = _create_result_fields(**kwargs)  # type: ignore[misc]
File "/omd/sites/sysco_prod01/lib/python3.12/site-packages/cmk/agent_based/v1/_checking_classes.py", line 447, in _create_result_fields
raise ValueError(f"'{name}' must be non-empty str or None, got {var}")
'notice' must be non-empty str or None, got

Local variables:

{'details': None,
'name': 'notice',
'notice': '',
'state': <State.OK: 0>,
'summary': None,
'var': ''}

It appears that it’s the python code on the checkmk server that cannot handle the code. But I don’t understand the meaning of the errors. And I suppose that I shouldn’t fiddle with the server code, right?

Has something changed in the behavior on the server side regarding the mk_oracle sql check section from 2.3 to 2.4?

I know that in version 2.5 the whole oracle plugin (mk_oracle) has been rewritten and has a new name, mk-oracle. But I’m not using this new plugin as it is not available for 2.4.

Anyone that can help me out on this?
Thank you,

/ric

2

can you show us the section output?

3

Yes, here it is.

<<<oracle_sql:sep(58)>>>
[[[DBNAME1|Oracle_Edition12]]]
details: Oracle Database 12c Enterprise Edition
exit: 0
perfdata:
long:
elapsed:.13087

This one puts out the Edition of the oracle db (Enterprise or Standard) and is the simpliest of the sqls we use.

But the problem is the same for all.

I followed the example in this thread to set up the custom sql

It has been working until 2.3.
Could it be that version 2.4 already has the changes implemented officially in 2.5 with the new oracle plugin where it uses oracle instant client instead of sqlplus?

4

If perfdata and long have no value, I would leave them out. Checkmk expects None or a non-empty str for long. I would also remove the blank after the <label>:, although I am not sure whether that actually makes a difference.

details:Oracle Database 12c Enterprise Edition
exit:0
elapsed:.13087
5

HI,

Yes, that did the trick. I removed long and perfdata and now it works as it should. Thanks for guiding me in the right direction and explaining the actual error message.

I still think something has change in the code on the server side in version 2.4 since it was working with my settins in 2.3 but crashed in 2.4. But that’s not an issue now that I know how it behaves and what is expected.

Really thankful for your help.

/ricardo

6

I’m glad this resolved your issue.

The new check API appears to be more restrictive, and during the migration of the Oracle checks to the new API, the handling of empty labels was likely not properly considered. As a result, this leads to this Python error.

7

Ok, that makes sense. Thank you again for the explanation

/ricardo