systemd module misses some files when checking for new unit files

[computator]

Description of Issue/Question

The systemd module seems to only check for new unit files in /etc/systemd/system. This causes issues with new managed unit files that are placed in other valid locations for systemd. service.running and other related states fail to detect the new unit files and reload systemd before starting/stopping or otherwise managing services thus causing the entire state to fail.

There are multiple valid paths for unit files. Personally I was using /usr/local/lib/systemd/system/ (which seems to be ubuntu specific?) but the systemd.unit man page lists a bunch for both user and system modes. The three main system mode ones seem to be:

• /etc/systemd/system
• /run/systemd/system
• /lib/systemd/system

The relevant code seems to be in _untracked_custom_unit_found() in modules/systemd.py:
https://github.com/saltstack/salt/blob/develop/salt/modules/systemd.py#L375

Setup

service-test:
  file.managed:
    - name: /usr/local/lib/systemd/system/blah.service
    - source: salt://blah.service
  service.running:
    - enable: true
    - require:
      - file: service-test

Versions Report

Salt Version:
           Salt: 2018.3.3
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.8
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.15rc1 (default, Nov 12 2018, 14:31:15)
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5
 
System Versions:
           dist: Ubuntu 18.04 bionic
         locale: UTF-8
        machine: x86_64
        release: 4.15.0-43-generic
         system: Linux
        version: Ubuntu 18.04 bionic
 

[dwoz]

@rlifshay Thanks for reporting this. Do you think you would be able to create a PR with a fix?

[Poil]

Hi,

It is a bad practice, user write services should never go in /run /lib but in /etc and should never been rewrited.
If need to overwrite an existent service, you should use an override configuration file /etc/systemd/system/myservice.service.d/override.conf.

Ref. https://askubuntu.com/questions/659267/how-do-i-override-or-configure-systemd-services

Best regards,

[computator]

@dwoz, I'm not familiar enough with the internals of salt to know if there's a better way to do this than just looping through a list of paths to check. If that's all there is to it, or someone can point me in the right direction, then yes I can look into making a pull request.

@Poil, yes I am aware, however /etc is for custom services and for machine specific overrides. /lib is intended for software that has been installed (something often done with salt), especially if it's a package intended for installation on multiple machines. /run is for units or overrides that are only temporary until reboot, and as such neither /etc or /lib is appropriate.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[computator]

Still an issue last I checked.

[stale]

Thank you for updating this issue. It is no longer marked as stale.