Glad that it worked for now. I'm afraid that rename will not survive an upgrade. Therefore, we need to follow this after each upgrade:

1. rename the file

mv /etc/zextras/service-discover/carbonio-message-dispatcher-xmpp.hcl \
/etc/zextras/service-discover/carbonio-message-dispatcher-xmpp.hcl.backup
systemctl restart service-discover

2. The systemctl mask carbonio-message-dispatcher should survive upgrades (the mask symlink lives in /etc/systemd/system/, which dpkg doesn't touch), so the renaming should be enough.

Let us know how it goes.!

I now updated to 26.6. It was the other way round, actually. :-) I couldn't run pending-setups successfully without unmasking carbonio-message-dispatcher first. But carbonio-message-dispatcher-xmpp.hcl didn't reappear during the update.

Afterwards, I masked carbonio-message-dispatcher again and then also masked carbonio-message-dispatcher-xmpp-sidecar as this service was in a restart loop.

Seems to have worked as intended.

It is good that the connection-refused chain cleared after the reboot. The reboot appears to have cleared the stale service-discoverd checks that lingered after the .hcl was moved aside.

The user@999.service restart loop looks like a separate thing to me. On a healthy Carbonio CE box, this user manager stays dormant: I just checked our test box (UID 999 = carbonio-prometheus there) and user@999.service, user-999.slice, and user-runtime-dir@999.service are all inactive (dead) with no journal entries, even though six prometheus processes are running as that UID right now.

Still, the restart loop usually points to something explicitly opening a session for UID 999 (a cron job, a monitoring agent, or a leftover loginctl enable-linger). If you'd like to pin it down, journalctl -u user@999.service --since "10 min ago" is usually enough to spot the trigger. Otherwise the box is fine to keep using.

Glad that it worked for now. I'm afraid that rename will not survive an upgrade. Therefore, we need to follow this after each upgrade:

1. rename the file

mv /etc/zextras/service-discover/carbonio-message-dispatcher-xmpp.hcl \
/etc/zextras/service-discover/carbonio-message-dispatcher-xmpp.hcl.backup
systemctl restart service-discover

2. The systemctl mask carbonio-message-dispatcher should survive upgrades (the mask symlink lives in /etc/systemd/system/, which dpkg doesn't touch), so the renaming should be enough.

Let us know how it goes.!

After stopping carbonio-message-dispatcher daemon, masking it, then moving carbonio-message-dispatcher-xmpp.hcl aside, and then restarting service-discover, I keep getting this in syslog and it seems to keep restarting user@999.service

2026-05-14T12:24:03.020886-06:00 carb service-discoverd: 2026-05-14T12:24:03.020-0600 agent: Check is now critical: check=ready
2026-05-14T12:24:07.369855-06:00 carb carbonio-preview-start.sh: " INFO 127.0.0.1:53236 - "GET /health/live/ HTTP/1.1" 200"
2026-05-14T12:24:08.022382-06:00 carb service-discoverd: 2026-05-14T12:24:08.021-0600 agent: Check is now critical: check=ready
2026-05-14T12:24:09.934562-06:00 carb service-discoverd: 2026-05-14T12:24:09.933-0600 agent: Check TCP connection failed: check=service:carbonio-storages-sidecar-proxy:1 error="dial tcp 127.78.0.3:21019: connect: connection refused"
2026-05-14T12:24:09.934720-06:00 carb service-discoverd: 2026-05-14T12:24:09.934-0600 agent: Check is now critical: check=service:carbonio-storages-sidecar-proxy:1
2026-05-14T12:24:10.595678-06:00 carb service-discoverd: 2026-05-14T12:24:10.595-0600 agent: Check TCP connection failed: check=service:carbonio-user-management-sidecar-proxy:1 error="dial tcp 127.78.0.5:21022: connect: connection refused"
2026-05-14T12:24:10.595788-06:00 carb service-discoverd: 2026-05-14T12:24:10.595-0600 agent: Check is now critical: check=service:carbonio-user-management-sidecar-proxy:1
2026-05-14T12:24:10.768208-06:00 carb service-discoverd: 2026-05-14T12:24:10.768-0600 agent: Check TCP connection failed: check=service:carbonio-ws-collaboration-db-sidecar-proxy:1 error="dial tcp 127.0.0.1:21024: connect: connection refused"
2026-05-14T12:24:10.768372-06:00 carb service-discoverd: 2026-05-14T12:24:10.768-0600 agent: Check is now critical: check=service:carbonio-ws-collaboration-db-sidecar-proxy:1
2026-05-14T12:24:11.415286-06:00 carb service-discoverd: 2026-05-14T12:24:11.414-0600 agent: Check TCP connection failed: check=service:carbonio-tasks-db-sidecar-proxy:1 error="dial tcp 127.0.0.1:21020: connect: connection refused"
2026-05-14T12:24:11.415419-06:00 carb service-discoverd: 2026-05-14T12:24:11.414-0600 agent: Check is now critical: check=service:carbonio-tasks-db-sidecar-proxy:1
2026-05-14T12:24:12.372883-06:00 carb carbonio-preview-start.sh: " INFO 127.0.0.1:56350 - "GET /health/live/ HTTP/1.1" 200"

I'm not sure if anything is actually "not working" but this is constantly spamming syslog, unsure what to do at this point. And I have updated to all CE packages from the main repos as of today.

Glad that it worked for now. I'm afraid that rename will not survive an upgrade. Therefore, we need to follow this after each upgrade:

1. rename the file

mv /etc/zextras/service-discover/carbonio-message-dispatcher-xmpp.hcl \
/etc/zextras/service-discover/carbonio-message-dispatcher-xmpp.hcl.backup
systemctl restart service-discover

2. The systemctl mask carbonio-message-dispatcher should survive upgrades (the mask symlink lives in /etc/systemd/system/, which dpkg doesn't touch), so the renaming should be enough.

Let us know how it goes.!

Thanks for the reply! I did what you wrote, and the logs stopped.

But, of course, service-discoverd was then unhappy that it couldn't reach carbonio-message-dispatcher-xmpp. So I renamed /etc/zextras/service-discover/carbonio-message-dispatcher-xmpp.hcl to carbonio-message-dispatcher-xmpp.hcl.off and restarted service-discoverd. Afterwards, nothing regarding message-dispatcher showed up in the logs anymore.

But I guess this won't survive an update, will it?

The solution you are thinking of is yet to be defined officially. Therefore, I would request you to approach with caution.

The mongooseimctl lines come from carbonio-message-dispatcher.service. As you could see in the official docs, carbonio-message-dispatcher-ce package is responsible for the Chats module. So stopping and masking the service (carbonio-message-dispatcher.service) should stop the mongooseimctl log entries. 

systemctl stop carbonio-message-dispatcher
systemctl mask carbonio-message-dispatcher

Try them and share your findings with us.

Also, don't remove any packages in a rush. That could break the infrastructure. 

Just now I found again that mongooseim is puking into the logs every 15s:

May 01 09:02:48 <my hostname> mongooseimctl: =ERROR REPORT==== 1-May-2026::09:02:48.750635 ===
May 01 09:02:48 <my hostname> mongooseimctl:     reason: function_clause
May 01 09:02:48 <my hostname> mongooseimctl:     stacktrace: <<"wpool_pool:g/2:334 mongoose_wpool_rdbms:get_rdbms_data_stats/2:64 safely:apply_and_log/4:58 mongoose_instrument_probe:call/3:20">>
May 01 09:02:48 <my hostname> mongooseimctl:     class: error
May 01 09:02:48 <my hostname> mongooseimctl:     what: probe_failed
May 01 09:02:48 <my hostname> mongooseimctl:     event_name: wpool_global_rdbms_stats
May 01 09:02:48 <my hostname> mongooseimctl:     labels: #{pool_tag => default}
May 01 09:02:48 <my hostname> mongooseimctl:     probe_mod: mongoose_wpool_rdbms
May 01 09:02:48 <my hostname> mongooseimctl:     stacktrace_args: <<"">>

If possible, I would like to either remove all packages related to chat or at least make sure that anything that is only required for chat will never be started on boot.

Is that possible in a way that will survive updates?

Thanks, Christian