Upgrade issues
Escaping-related
Exceeded character limit for function parameters after upgrade
Since Zabbix 7.0, a backslash in a quoted string parameter of a history function is treated as an escape character instead of a literal character.
During the upgrade from pre-7.0 versions, such backslashes are doubled, so that the function receives the same value as before.
For example, find(/host/key,,"regexp","error \d+") becomes find(/host/key,,"regexp","error \\d+").
This leads to longer parameters and may result in broken trigger functions when the parameter length exceeds 255 characters.
To avoid this problem, manually move long parameters into user macros before or after the upgrade, as shown in the example below.
For readability, long sequences of backslashes in the example below are shown as placeholders.
Each placeholder stands for the stated number of backslash characters written one after another without spaces (e.g., <3 backslashes> means \\\).
Suppose that, in Zabbix 6.0, you have:
- A
vfs.file.contents[/tmp/ONE]item that reads the/tmp/ONEfile, which contains 114 backslashes followed bya:
<114 backslashes>a
- Calculated_item_228 and Trigger_228 that use an expression, which looks for 114 backslashes followed by
a(in regular expressions,\\stands for one literal backslash):
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp","<228 backslashes>a")
- Calculated_item_232 and Trigger_232 that use an expression, which looks for 116 backslashes followed by
a:
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp","<232 backslashes>a")
With this configuration:
- Calculated_item_228 returns
1and Trigger_228 goes into the PROBLEM state, because the file contains the 114 backslashes followed byathat the expression looks for. - Calculated_item_232 returns
0and Trigger_232 stays in the OK state, because the file contains only 114 backslashes, while the expression looks for 116.
During the upgrade to Zabbix 8.0, Zabbix server will log a warning for each trigger function parameter that is too long to be converted (search the log for MANUAL INTERVENTION IS REQUIRED to find all affected parameters).
For example, the following warning will be logged for Trigger_228:
2485502:20250228:115442.236 DBpatch_6050165(): cannot save in DB function parameter: resulting size 477 is longer than the maximum 255.
functionid:33792 function:'find'
used on host: 'Zabbix server'
in trigger: 'Trigger_228'.
Current parameter value:
'$,1m:now,"regexp","<228 backslashes>a"'
Resulting escaped value would be:
'$,1m:now,"regexp","<456 backslashes>a"'
DB upgrade and Zabbix server can continue to run, but to make sure this function works correctly
MANUAL INTERVENTION IS REQUIRED !
Need to manually reduce the size of this parameter with macro as a workaround.
After the upgrade, the calculated items will work as before (e.g., 228 backslashes will become 456).
However, both triggers will go into the PROBLEM state, because their parameters were not converted.
Zabbix 8.0 reads every two backslashes as one, and the regular expression halves them again:
Trigger_228 looks for 57 backslashes followed by a, and Trigger_232 looks for 58.
The file contains 114 backslashes followed by a, so both patterns are found in it.
To fix this, move the long values to user macros:
| Macro | Value |
|---|---|
{$228_BACKSLASHES_A} |
<228 backslashes>a |
{$232_BACKSLASHES_A} |
<232 backslashes>a |
Then use the macros in the expressions of Trigger_228 and Trigger_232:
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp",{$228_BACKSLASHES_A})
find(/Zabbix server/vfs.file.contents[/tmp/ONE],1m:now,"regexp",{$232_BACKSLASHES_A})
Now only Trigger_228 will go into the PROBLEM state, as before the upgrade. The calculated items do not need to be changed, but you can update them in the same way for consistency.