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.

2 Likes