I'd like to completely remove the chat module from my Carbonio installation. Nobody is using it, it is disabled for all my users, and yet it causes the most trouble, often requiring manual intervention after updates.
Just now I found again that mongooseim is puking into the logs every 15s:
May 01 09:02:48 <my hostname> mongooseimctl[4510]: =ERROR REPORT==== 1-May-2026::09:02:48.750635 ===
May 01 09:02:48 <my hostname> mongooseimctl[4510]: reason: function_clause
May 01 09:02:48 <my hostname> mongooseimctl[4510]: 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[4510]: class: error
May 01 09:02:48 <my hostname> mongooseimctl[4510]: what: probe_failed
May 01 09:02:48 <my hostname> mongooseimctl[4510]: event_name: wpool_global_rdbms_stats
May 01 09:02:48 <my hostname> mongooseimctl[4510]: labels: #{pool_tag => default}
May 01 09:02:48 <my hostname> mongooseimctl[4510]: probe_mod: mongoose_wpool_rdbms
May 01 09:02:48 <my hostname> mongooseimctl[4510]: stacktrace_args: <<"[size,undefined]">>
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
@zottel
The solution you are thinking of is yet to be defined officially. Therefore, I would request you to approach with caution.
The mongooseimctl[PID] 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.
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?
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.!
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-discover2. 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[27297]: 2026-05-14T12:24:03.020-0600 [WARN] agent: Check is now critical: check=ready
2026-05-14T12:24:07.369855-06:00 carb carbonio-preview-start.sh[1679]: "[2026-05-14 12:24:07,368] INFO [uvicorn.access.send:473] 127.0.0.1:53236 - "GET /health/live/ HTTP/1.1" 200"
2026-05-14T12:24:08.022382-06:00 carb service-discoverd[27297]: 2026-05-14T12:24:08.021-0600 [WARN] agent: Check is now critical: check=ready
2026-05-14T12:24:09.934562-06:00 carb service-discoverd[27297]: 2026-05-14T12:24:09.933-0600 [WARN] 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[27297]: 2026-05-14T12:24:09.934-0600 [WARN] agent: Check is now critical: check=service:carbonio-storages-sidecar-proxy:1
2026-05-14T12:24:10.595678-06:00 carb service-discoverd[27297]: 2026-05-14T12:24:10.595-0600 [WARN] 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[27297]: 2026-05-14T12:24:10.595-0600 [WARN] agent: Check is now critical: check=service:carbonio-user-management-sidecar-proxy:1
2026-05-14T12:24:10.768208-06:00 carb service-discoverd[27297]: 2026-05-14T12:24:10.768-0600 [WARN] 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[27297]: 2026-05-14T12:24:10.768-0600 [WARN] 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[27297]: 2026-05-14T12:24:11.414-0600 [WARN] 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[27297]: 2026-05-14T12:24:11.414-0600 [WARN] 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[1679]: "[2026-05-14 12:24:12,372] INFO [uvicorn.access.send:473] 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.
Actually it looks like that connection refuse thing went away after rebooting the VM. User@999.service keeps restarting according to syslog, but I'm unsure if that's "working as intended" or not. Currently I do NOT get the connection refused by service-discoverd that I mentioned in my immediately previous log paste (after rebooting the VM).
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.