Carbonio – zmcontrol death

Carbonio has been evolving consistently and has finally achieved compatibility with Ubuntu 24.04, which is highly advantageous due to the significant security enhancements and performance improvements offered by the newer operating system.

There is a clear improvement in the overall performance of the environment, and we are very pleased with this advancement.

It’s not just zmcontrol—all CLI commands used to manage the “ctl”-type services, such as zmproxyctl, zmmtactl, and zmclamdctl, no longer work.

From now on, all services are managed exclusively through systemctl, requiring users to relearn certain commands and adapt to new concepts. The first and most evident change is that these services are no longer executed under the zextras user but directly as root.

Services are managed via the systemctl command, followed by options such as start, stop, restart, and status to perform the desired actions.

For example, to list all services would be done as follows:

systemctl --type=service

If you wish to filter the output, you can use the pipe operator, like this:

systemctl --type=service | grep carbonio

The systemctl also allows grouping a set of services and commands into a target. A good example is the carbonio-mta.target. There is no standalone service named mta; instead, it is a collection of multiple services that are started or stopped together as a unit through this target.

To find out which services are part of a target, use the list-dependencies option as follows:

systemctl list-dependencies carbonio-mta.target

It is therefore clear that the carbonio-mta target is a grouping of the services listed above.

Carbonio on Ubuntu 24.04 introduces 4 targets. They are:

carbonio-appserver.target
carbonio-directory-server.target
carbonio-mta.target
carbonio-proxy.target

Below is a table listing the services previously managed via zmcontrol and their corresponding management using systemctl:

One important aspect of this change is systemctl‘s ability to execute services in parallel. Instead of waiting for one service to finish before launching the next, systemctl starts multiple services concurrently. While this feature significantly improves efficiency, it can also introduce potential issues.

In the testing environment, we figured that systemctl attempts to start a service even if a previously needed service is not running, resulting in startup failures.

Another noteworthy point is that some services may take a few additional seconds to become fully operational—even after the systemctl status command reports an “OK” or active state.

This is a new environment, and we will need time to adjust to its unique characteristics. However, this change represents a clear step forward, and we are confident that, shortly, these adjustments will no longer be novelties, and everyone will benefit from a more robust and efficient system.

Published: 10/08/2025 | Updated: 16/08/2025