systemd unit path defined in service_files_dir

[cfelder]

I would like to raise the discussion on the default value for the systemd units generated using this role (service_files_dir).

The previous default /etc/systemd/system has been changed to /usr/local/lib/systemd/system by @Yajo with commit fe02a9f6 included in release 2.2.0.

Referencing man 5 systemd.unit:

/usr/lib/systemd/system and /usr/local/lib/systemd/system is meant for installed packages whereas /etc/systemd/system is meant for local configuration.

I would prefer to keep the previous default because imho the unit files generated in this playbook fits more into the local configuration section. Furthermore with this change we loose some backward compatibility because you cannot remove unit files using -e container_state=absent for deployments prior to 2.2.0.

This is no show stopper as you could always overwrite the defaults but I would like to have some discussion on this topic.

Looking forward to have some fruitful discussion here. Best Christian

[ikke-t]

I keep mine under etc.

[yajo]

The configs for packages you install from your OS will usually land in /usr/lib/systemd/system, not in /usr/local/lib/systemd/system, so the local part is not touched by them.

As you see in FHS:

/usr/local Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories (e.g., bin, lib, share).

Also, if you do actions such as systemctl disable a service, the change would go into /etc. That's why I considered /usr/local/lib/systemd/system the most correct place to put definitions: they are local to the host, and the system will keep them available even if you manually disable or mask them using CLI.

[birkenfeld]

To repeat, Systemd's own docs say:

/etc/systemd/system System units created by the administrator /usr/local/lib/systemd/system System units installed by the administrator

I would argue that configuration rolled out by ansible is not "installed by the administrator". It is not part of an installed software package etc.

[yajo]

It is not part of an installed software package

Isn't that the definition of "installed by the administrator"?

[c-erb]

There is a discussion about this topic also in stackexchange but the majority seems to expect the systemd units in /etc/systemd/system, which is also the place I would prefer as a default.

[yajo]

The point is that if you put them in /usr/local/lib/systemd/system, you'll still be able to have 100% local systemd functionality, such as overriding this role's things on your own local /etc files, or executing systemctl edit or systemctl disable.

If you make the role write to /etc and then you do some of those manual operations and then you execute the role again, the role will undo your manual changes.

That said, as long as it's configurable, I don't care what's the default.

[cfelder]

A happy new year to everybody

I would like to thank you for the discussion.

imho there are valid reasons to do this the one or the other way around. I am understanding your motivation @Yajo for having the files in /usr/local/… directory tree now.

Fortunately the path is configurable. There is just one thing I would like to point out here: Introducing a change in the default value for the unit file is a breaking change for existing deployments and it would be nice to either take backward compatibility into account or to raise the major version number to indicate there is a breaking change.

There are other changes which did not take backward compatibility into account as well.

I am looking forward how this role will evolve and would like to thank @ikke-t, @Yajo and all contributors.