# Icinga 2.16 upgrade: sudden flood of warnings ("Service object name too long" / ctrl characters) on config that was clean in 2.15 **URL:** \ **Category:** Icinga 2\ **Tags:** icinga2\ **Created:** [May 13, 2026, 1:18pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441 "2026-05-13T13:18:28Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Kuly2Fraise](https://community.icinga.com/letter_avatar_proxy/v4/letter/k/f14d63/32.png) [@Kuly2Fraise](https://community.icinga.com/u/Kuly2Fraise)\ **Post date:** [May 13, 2026, 1:18pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/1 "2026-05-13T13:18:28Z")
Hello, Since upgrading our Icinga servers from **2.15** to **2.16.0-1** , we are seeing a strong increase of config warnings during validation, while the exact same configuration was working fine before on 2.15. The warnings look like this: ```auto warning/config: Object name of type 'Service' is too long (length: 315, max: 255). warning/config: Object name of type 'Service' contains ctrl or newline characters, which may cause problems in some contexts. ``` They are triggered from an `apply Service for (...)` rule: ```auto apply Service for (port in host.vars.access_ports) to Host { ``` Example hosts impacted: - [acc-fo-lamb-01.net.test.net](http://acc-fo-lamb-01.net.test.net) - [acc-fo-para-01.net.test.net](http://acc-fo-para-01.net.test.net) - [acc-fo-gran-01.net.test.net](http://acc-fo-gran-01.net.test.net) Important points: - Hostnames themselves are normal length and do not contain special characters. - This happens on many/all hosts using this rule. - On **Icinga 2.15** , same config produced no such warnings. - The issue only appeared after upgrading the Icinga servers. Our suspicion is that one of the generated values inside `host.vars.access_ports` may now be interpreted differently in 2.16, or that validation became stricter. This is causing operational issues for us because we use an internal tool that generates and deploys Icinga config automatically. It runs the validation command remotely through Paramiko, and because of the huge amount of warnings, command execution becomes very long and eventually times out while waiting for the full output. So our questions are: 1. Did something change in Icinga 2.16 regarding object name generation for `apply for` rules? 2. Were checks on control/newline characters tightened recently? 3. Is there a recommended way to sanitize generated service names coming from arrays/dictionaries in `apply for` loops? 4. Could this be considered a regression if the exact same config was accepted cleanly in 2.15? Any guidance would be appreciated. Thanks. Nathan ---
**Author:** ![apenning](https://community.icinga.com/user_avatar/community.icinga.com/apenning/32/7669_2.png) [@apenning](https://community.icinga.com/u/apenning)\ **Post date:** [May 13, 2026, 1:36pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/2 "2026-05-13T13:36:17Z")
The database schema only allows object names of up to 255 characters. Prior to Icinga 2 version 2.16.0, this would result in errors further down the pipeline, either in Icinga DB or in the deprecated IDO. The only change in Icinga 2 was the introduction of the warning, as such long object names have always resulted in potential errors. Btw, the errors are about the service names, as the log shows and not for your short hosts. More details are available in [Icingadb crashes on too long service name · Issue #1101 · Icinga/icingadb · GitHub](https://github.com/Icinga/icingadb/issues/1101) and [Warn on problematic object names · Issue #10768 · Icinga/icinga2 · GitHub](https://github.com/Icinga/icinga2/issues/10768). ---
**Author:** ![Kuly2Fraise](https://community.icinga.com/letter_avatar_proxy/v4/letter/k/f14d63/32.png) [@Kuly2Fraise](https://community.icinga.com/u/Kuly2Fraise)\ **Post date:** [May 13, 2026, 2:01pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/3 "2026-05-13T14:01:24Z")
> [@apenning](#): > > Btw, the errors are about the service names, as the log shows and not for your short hosts. Thank you for your reply, that makes sense regarding the 255-character database limit and the fact that the warning was only introduced in Icinga 2.16. However, in our case, based on our configuration, we do not understand how the generated service name could exceed 255 characters. Our apply rule is: ```auto apply Service for (port in host.vars.access_ports) to Host { import if (port.service_template) {port.service_template} else {"service-5m"} name = port.name display_name = if(port.display_name) {port.display_name} else {"Port "+port.real_name} check_command = "check_switch_port" vars.port_name = port.real_name vars.ifindex = if(port.ifindex) {port.ifindex} else {port.real_name} vars.check_state = if (port.monitoring) {"yes"} else {"no"} vars.relative_state = if (port.absolute_state) {"no"} else {"yes"} vars.warning = if (port.warning) {port.warning} else {"85,-1,-1"} vars.critical = if (port.critical) {port.critical} else {"95,-1,-1"} vars.service_groups = if (port.service_groups) {port.service_groups} else {[]} vars.notifications = if (port.notifications) {port.notifications} else {[]} vars.type = if (port.type) {port.type} else {""} } ``` And `port.name` values are short strings such as: ```auto port_gigabitethernet1_0_1 port_gigabitethernet1_0_10 port_gigabitethernet1_0_11 ``` So if I understand correctly, the generated service object name should be something like: ```auto acc-fo-gran-01.net.test.net!port_gigabitethernet1_0_1 ``` Character count: - `acc-fo-gran-01.net.test.net` = 27 - `!` = 1 - `port_gigabitethernet1_0_1` = 24 **Total = 52 characters** Even with longer interface names such as: ```auto acc-fo-gran-01.net.test.net!port_tengigabitethernet1_1_1 ``` This would still remain far below 255 characters. We also initially suspected that some hidden or non-printable characters could be present in the generated data (for example in `host.vars.access_ports` or related fields), which could potentially influence how object names are evaluated. However, even after validating and sanitizing this part, the warnings still occur. That is why we are struggling to understand where lengths such as 315 or 323 could come from, or what exactly is being concatenated internally to reach those values. Is there any change in Icinga 2.16 regarding how object names are constructed or validated for `apply for` rules that could explain this behavior? Thank you 🙂 ---
**Author:** ![apenning](https://community.icinga.com/user_avatar/community.icinga.com/apenning/32/7669_2.png) [@apenning](https://community.icinga.com/u/apenning)\ **Post date:** [May 13, 2026, 2:32pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/4 "2026-05-13T14:32:26Z")
Please feel free to share the complete (but redacted) log output. This might help. Furthermore, you can add a `log` DSL function call to the Service object, helping identifying the length. For your previously pasted Service snippet, just add the following line somewhere within the object body: ```auto log(host.name + "!" + name + "\t" + len(host.name + name)) ``` Afterwards, fire an `icinga2 daemon -C --dump-objects` and scroll through the output. As another idea, use the Icinga 2 [API to query](https://icinga.com/docs/icinga-2/latest/doc/12-icinga2-api/#querying-objects) all service objects. Take the following as an inspiration, where `$user` is an Icinga 2 ApiUser with enough permissions to query all objects and `$pass` its password. Please check the output. ```auto curl -k -s -S \ -u "$user:$pass" \ -H 'Accept: application/json' \ 'https://localhost:5665/v1/objects/services/' \ | jq -r '.results[].name | [length, @text] | @tsv' \ | sort -n -k 1 -r \ | head ``` ---
**Author:** ![bberg](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/b782af/32.png) [@bberg](https://community.icinga.com/u/bberg)\ **Post date:** [May 13, 2026, 2:35pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/5 "2026-05-13T14:35:03Z")
Maybe verify the actual service names. You can do this pretty easy in the icinga2 console: ```auto icinga2 console --connect https://root:password@localhost:5665/ get_services(get_host(NodeName)).map(s => s.name) ["1", "disk", "disk /", "http", "icinga", "load", "ping4", "ping6", "procs", "ssh", "swap", "users"] ``` ---
**Author:** ![yhabteab](https://community.icinga.com/letter_avatar_proxy/v4/letter/y/ac91a4/32.png) [@yhabteab](https://community.icinga.com/u/yhabteab)\ **Post date:** [May 13, 2026, 4:32pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/6 "2026-05-13T16:32:31Z")
> [@Kuly2Fraise](#): > > And `port.name` values are short strings such as: > > ```auto > port_gigabitethernet1_0_1 > port_gigabitethernet1_0_10 > port_gigabitethernet1_0_11 > > ``` > > So if I understand correctly, the generated service object name should be something like: > > ```auto > acc-fo-gran-01.net.test.net!port_gigabitethernet1_0_1 > > ``` > > Character count: That’s not quite correct! The length restriction doesn’t apply on the `host.name!service.name` part but on each of them separately. The `name = port.name` statement won’t be executed at the time when Icinga 2 performs such kind of name validations. That assignment is executed much later, when the object body actually gets evaluated. What is going on with your apply rule is as follows: First, looking at your apply rule and its usages, I assume some of your hosts have `access_ports` custom vars defined as follows: ```auto vars.access_ports = [ { name = "port_gigabitethernet1_0_1" real_name = "..." ... }, { name = "port_gigabitethernet1_0_10" real_name = "..." ... }, { name = "port_gigabitethernet1_0_11" real_name = "..." ... } ] ``` So, when Icinga 2 evaluates the `apply Service for (port in host.vars.access_ports)` statement, the `port` variable is assigned the value of each of the elements of the `access_ports` array, which are dictionaries (and may contain much more attributes in your case than the ones shown above). Icinga 2 then use `port` as a unique identifier for the service instances being created, and thus performs name validations on the `port` variable, which is a dictionary, and not on the `name` attribute of the dictionary as you might have expected. In this case, the `port` dictionary converted to a string will look something like this (exactly how it’s defined): ```auto { name = "port_gigabitethernet1_0_11" real_name = "..." ... } ``` So, if that dictionary has a lot of attributes, the resulting string will be very long, and thus the name validation will fail with the error message you are seeing. The warnings about the ctrl/newline characters are also related to the fact that the string representation of the `port` dictionary is prettified with newlines and indentation, which is not really suitable for a service name. See example of the log output below: ( **EDIT:** you won’t see the faulty object name in your case since Icinga 2 doesn’t include it in the logs as it can be huge and possibly mess up the logs). ```auto warning/config: Object name '{ name = "port_gigabitethernet1_0_11" real_name = "..." ... }' of type 'Service' contains ctrl or newline characters, which may cause problems in some contexts. Location: in icinga2.conf: 70:1-70:50 icinga2.conf(70): apply Service for (port in host.vars.access_ports) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` To fix this issue, you should change the type of the `host.vars.access_ports` variable to be a dictionary instead of an array like this: ```auto vars.access_ports = { "port_gigabitethernet1_0_1" = { real_name = "..." ... }, "port_gigabitethernet1_0_10" = { real_name = "..." ... }, "port_gigabitethernet1_0_11" = { real_name = "..." ... } } ``` Then, change your apply rule to a dictionary based iteration instead of the array elements like this: ```auto apply Service for (name => port in host.vars.access_ports) { ... } ``` You can then use the `port` variable to access the other attributes just like you were doing before, but now the `name` variable will contain the unique identifier for the service instance, so you don’t need to assign it manually via the `name = port.name` statement anymore. That should fix all your warnings! ---
**Author:** ![MrPink](https://community.icinga.com/letter_avatar_proxy/v4/letter/m/ecc23a/32.png) [@MrPink](https://community.icinga.com/u/MrPink)\ **Post date:** [July 8, 2026, 12:53pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/7 "2026-07-08T12:53:21Z")
Well, this “solution” is a request to rewrite the config, which would be a huge effort for us. We heavily rely on arrays instead of dictionaries to apply all sorts of services to hosts. Apparently, there is no way to suppress this specific warning either. So we did a hacky workaround. First we registered a global function to dictify an array: ```auto globals.dictify = function (arr) { var dict = {} for (i in range(len(arr))) { dict["el"+i] = arr[i] } return dict } ``` Then, we adjusted the service rules like this: ```auto # before the fix (caused massive warnings): apply Service for (config in host.vars.custom_array_of_objects) { ... } # after the fix (no warnings): apply Service for (myel => config in dictify(host.vars.custom_array_of_objects)) { ... } ``` This seems to work. Maybe @yhabteab can give a feedback on if that is a viable solution or should be avoided. Thanks in advance, Marco Edit: Just for the record: In these cases the service name gets set explicitly, of course. ---
**Author:** ![yhabteab](https://community.icinga.com/letter_avatar_proxy/v4/letter/y/ac91a4/32.png) [@yhabteab](https://community.icinga.com/u/yhabteab)\ **Post date:** [July 27, 2026, 2:32pm UTC](https://community.icinga.com/t/icinga-2-16-upgrade-sudden-flood-of-warnings-service-object-name-too-long-ctrl-characters-on-config-that-was-clean-in-2-15/15441/8 "2026-07-27T14:32:21Z")
> [@MrPink](#): > > This seems to work. Maybe @yhabteab can give a feedback on if that is a viable solution or should be avoided. Hi, yes that works but this is simply because you’re making use of an Icinga DSL internals that shouldn’t have been exposed to users in the first place. That is, allowing users to explicitly override the object names via the `name` attribute. Normally, the `name` attribute and the one used in the `object Service/Host.. "name" {` should never differ but in your case they will. As a consequence, you will not be allowed to create a service object with `"el"+i` and the one used to explicitly set the `name` attr in your apply rule definition as Icinga 2 will use these names to register the service object at two different locations. Thus, if transforming the arrays to dictionaries isn’t viable for you, then yes, this might be a possible workaround but don’t be surprised if you get a mysterious `object already exists` error in the future even though the API or `object list` command lists no objects with such names. We might fix this in the future or forbid users to explicitly set the `name` attr, but we don’t have a concrete plan for that yet :).