Systemctl does not work as expected

Many systemctl sub commands do not play well with the way that clear linux deploys systemd unit files.
systemctl is-enabled
systemctl list-unit-files
systemctl enable/disable

It looks like these commands only access and modify data under /etc/systemd/system/.wants , but many packages only have links to their unit files under /usr/lib/systemd/system/.wants

Some examples I’ve been testing on are open-vm-tools.service and swupd-update.timer. Both of those services are running on my server as confirmed with systemctl status, when I check systemctl is-enabled and systemctl list-unit-files those services are listed as disabled, but if I reboot the server those services run on startup.
systemctl disable open-vm-tools.service also does not disable the service, I need to run systemctl mask open-vm-tools.service to disable the service.

Is there some alternative to systemctl that I should be using on Clear linux to properly interface with systemd?
On most systemd systems the following command would list what services are enabled
#systemctl list-unit-files |awk ‘$2==“enabled” {print}’
Is there a command under Clear linux to list what systemd units are enabled?

There is not. Unfortunately.

I’m well aware of this short-coming. The reason is complex: systemd actually has a method for “factory-enabled” services, but we do not wish to use it.

The biggest problem with the factory method that systemd provides is that it doesn’t allow the OS vendor to retroactively remove default services. It works by creating a factory “template” that gets copied to /etc/systemd/system upon installation. This makes it impossible for the OS vendor to stop and remove services that are obsolete - because in Clear Linux we have a hard “do not mess around in /etc rule” that it conflicts with. We really want to be able to remove obsolete services, because for instance they could be insecure, and we really want to shut them down and disable them.

We also do not like to see lots of symlinks under /etc/systemd/system for things that are OS defaults. They add no value and make maintenance more difficult - there is no differentiation between a symlink that the OS made and one that the sysadmin made, for instance. We don’t like that - so we opted for a method where there are no OS made symlinks under /etc/systemd/system instead.

The end result is that systemctl does not have the needed code to know about symlinks under /usr/lib/systemd/system/*.wants. We could patch it to do that, and I have not done so. I agree it’s worth looking to do that, though.


The issue I can see with the above and have stumbled upon is when you try and disable & mask the systemd-resolved service.

I favour NetworkManager for my DNS resolution, in particular with OpenVPN which will look to update /etc/resolv.conf. When systemd-resolved is in play, this does not work.

Disabling it, and restarting NetworkManager worked fine until the next reboot.

When making systemd-resolved, it will still attempt to start, however, the DNS resolution will fail due to the symbolic link of the service going to /dev/null.

There needs to be a solution to be able to actually disable a service fully, and not just on the current session.


I did find a way around this, for clarity which came down to systemd-tmpfiles creating the link on boot. This is done by way of source config files that needed to be amended accordingly.

This does appear to be resolved in further releases of systemd, however.


A slight update on the above, which I found after updating to version 33900, systemd-tmpfiles.conf no longer houses the symbolic link which is created on boot to /etc/resolv.conf. This has now moved to etc.conf instead. I had to, again, comment / remove the requirement for a resolv.conf link, remove the link that had already been created, then reboot my system again.