When using a very large argument key icingadb will see a fatal error and quit #791
Comments
|
Thanks for using Icinga DB and reporting your crash. It seems like the issue roots in your long argument key. The current schema defines: icingadb/schema/pgsql/schema.sql Line 838 in 27d27d4 However, your key extends 64 chars: Edit: My brain shut down after reading the first parts of your java class path.. My char counting was not necessary. Sorry :) |
|
Thanks for responding and highlighting the issue. Our brains all shut down reading java classes because we're so conditioned to its verbose-ness. What would be the suggested workaround for argumentless parameters that are over 64 chars long? I feel my bash script approach is a bit flakey and was curious if there was a better solution. |
|
First, I will compare how the "old" Icinga 2 IDO handled this. Then I would try to find out why it was limited to 64 chars and look for any platform specific limitations. If there are none, I would increase the column size. Please allow me some time to look at this. In the meantime, I would suggest that you continue with your mitigation of the wrapper script. I would advise against manually altering the schema on your end, as this could have unintended side effects and break future schema upgrades. |
Icinga 2I have integrated your configuration in my test setup and was directly able to reproduce the Icinga DB crash. However, Icinga 2's IDO continued to work. As I was unable to find a direct match for Icinga DB's Then there was Icinga/icinga2#9887, which has some similarity to this issue. There, the argument length was made to fit the length of the platform, which I will look at next. Technical LimitationsAs always, the limits are platform- and architecture-specific. Based on this very detailed Stack Exchange post, on a non-ancient Linux system, both Similar limits are being enforced for other Unix-like operating systems, as this document explains. For example, that's the limit I get on a current OpenBSD: While I am not very familiar with Windows, its documentation notes a limit of 8191 characters. Icinga DBAs written above, the Icinga DB schema limits icingadb/schema/pgsql/schema.sql Line 944 in 27d27d4 icingadb/pkg/icingadb/v1/command.go Line 21 in 7c068d4 It seems like there is no usage from the Go end, but its available there mostly for Icinga DB Web. However, it should be noted that there are multiple tables with an
Then, there are is also the Going back to the first schema, being introduced in 05d5e97, this field was always from the type As a first test, I have just altered the type from |
I just had another idea in this regard. As being argument-less, you can revert the logic and make it key-less. To be precise, set |
From the beginning, the Icinga DB's schema allowed 64 characters for
both the command arguments and environment variable names[0]. In
particular, this affects CheckCommand, EventCommand and
NotificationCommand Icinga 2 objects.
But if a command with either an argument key or an environment variable
that is longer than 64 characters was defined in Icinga 2, Icinga DB
will try to insert it into the database and may end up crashing.
Although it may seem large enough, it is sometimes exceeded.
After evaluating that there was no technical limitation[1], the limit
was increased to 255 characters. This limit was chosen over the wider
text type as it allows indexes in the future and requires less space.
For example, the following CheckCommand was not possible before:
> object CheckCommand "icingadb-i791" {
> import "plugin-check-command"
> command = [ "/bin/true" ]
> env = {
> "THAT_ARE_64_AS_WOW_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" = "huhu"
> }
> arguments = {
> "java.class.that.was.used.as.an.argument.that.was.eighty.seven.characters.long.and.broke" = {
> value = "F"
> }
> }
> }
Another thing was a type difference between the MySQL and PostgreSQL
schemas. While the MySQL schema defined argument_key_override as
varchar(64), in PostgreSQL it was a citext. So it was changed to
varchar(255) in MySQL and kept as it was in PostgreSQL.
Closes #791.
[0]: 05d5e97
[1]: #791 (comment)
|
Hi, I can confirm that the skip_key workaround works fine. Thanks for your help. |
Describe the bug
I am uncertain as to whether this is a bug or something that needs more warnings in Icinga.
I was running a check command with a java library that was loaded like this:
java -cp "lib/*" java.class.that.was.used.as.an.argument.that.was.eighty.seven.characters.long.and.broke ....omittedThe class parameter has no flag/option/argument prior, so this may be part of the issue.
In the command template I put this as an argument which all worked fine from the check perspective.
However icingadb didn't like it:
Expected behavior
A warning that argument keys have a limit, or this is a bug.
I have resolved this by using a bash script wrapper. What advice would you give for anyone else who has a similar issue?
Your Environment
Include as many relevant details about the environment you experienced the problem in
Using the following docker images:
"icinga/icingaweb2:2.12.1"
"icinga/icinga2:2.14.2"
"icinga/icingadb:1.2.0"
"redis:7.2.5"
Additional context
I ran this in a docker environment with MySQL.
The text was updated successfully, but these errors were encountered: