Setting { providers: { service: systemd } } does work in minion config.

[alinefr]

This is a masterless setup for kali linux.

My /etc/salt/minion has:

providers:
  service: systemd

If I do this:

openvas-manager:
  service.running:
    - enable: True

It only checks if openvas-manager.service is enabled, but it runs /etc/init.d/openvas-manager start instead of systemctl start openvas-manager.service start

[INFO    ] Running state [openvas-manager] at time 20:51:46.158106
[INFO    ] Executing state service.running for openvas-manager
[INFO    ] Executing command 'ps -efH' in directory '/root'
[INFO    ] Executing command ['systemctl', 'is-enabled', 'openvas-manager.service'] in directory '/root'
[INFO    ] Executing command '/etc/init.d/openvas-manager start' in directory '/root'
[ERROR   ] Command '/etc/init.d/openvas-manager start' failed with return code: 1
[ERROR   ] output: Starting OpenVAS Manager: ERROR.
[INFO    ] Executing command ['systemctl', 'is-enabled', 'openvas-manager.service'] in directory '/root'
[INFO    ] Executing command 'ps -efH' in directory '/root'
[INFO    ] Executing command ['systemctl', 'is-enabled', 'openvas-manager.service'] in directory '/root'
[ERROR   ] Service openvas-manager is already enabled, and is dead
[INFO    ] Completed state [openvas-manager] at time 20:51:51.246761

In order to properly execute invoking systemctl <action> <daemon>.service it needs:

openvas-manager:
  service.running:
    - enable: True
    - provider: systemd

   Salt Version:
               Salt: 2015.8.8

    Dependency Versions:
             Jinja2: 2.8
           M2Crypto: 0.21.1
               Mako: 1.0.3
             PyYAML: 3.11
              PyZMQ: 15.1.0
             Python: 2.7.11 (default, Jan 11 2016, 21:04:40)
               RAET: Not Installed
            Tornado: 4.2.1
                ZMQ: 4.1.4
               cffi: Not Installed
           cherrypy: Not Installed
           dateutil: 2.4.2
              gitdb: 0.6.4
          gitpython: 1.0.1
              ioflo: Not Installed
            libgit2: Not Installed
            libnacl: Not Installed
       msgpack-pure: Not Installed
     msgpack-python: 0.4.6
       mysql-python: 1.3.7
          pycparser: Not Installed
           pycrypto: 2.6.1
             pygit2: Not Installed
       python-gnupg: Not Installed
              smmap: 0.9.0
            timelib: Not Installed

    System Versions:
               dist: Kali kali-rolling kali-rolling
            machine: x86_64
            release: 4.3.0-kali1-amd64
             system: Kali kali-rolling kali-rolling

[Ch3LL]

@alinefr I was not able to replicate this switching from systemd to rh_service. Are you seeing this on all services on that box or just openvas-manager.

[alinefr]

@Ch3LL, I'm seeing this on all services. service.running treats the service as SysV not as systemd, except if I explicitly add provider: systemd inside service.running.

sudo salt-call grains.get init
local:
    systemd

While

sudo salt-call test.provider service
local:
    service

In a ubuntu systemd enabled box, this last command returns "systemd". It seems that someway salt detects my Kali box as SysV

This is what happens for services which does not have any /etc/init.d scripts (pure systemd):

metasploit-service:
  service.running:
    - name: metasplout
    - enabled: True

[INFO    ] Running state [metasploit] at time 13:21:58.228641
[INFO    ] Executing state service.running for metasploit
[ERROR   ] The named service metasploit is not available
[INFO    ] Completed state [metasploit] at time 13:21:58.231289

So, someway salt is not properly detecting systemd in Kali. Even then, enabling { providers: { service: systemd } } in minion config is not enough.

[mstarostik]

Maybe related? I'm on a Gentoo system with systemd. So I set providers: { service: systemd } in the minion config as well and this exposes a somewhat weird behaviour. The setting is honoured just fine unless and until the service.* state is preceded by a pkg.* state. Case A and B below differ only in the order of the service.running and pkg.installed states. No difference in minion config or anything. This is a minimal test case, It is reproducible with pkg.* and service.* states distributed accross different SLS files to the same outcome. As long as the pkg.* state is run first, service fails to pick up its provider setting.

Case A:

test:
  service.running:
    - name: systemd-journald
  pkg.installed:
    - name: virtual/service-manager

[DEBUG   ] LazyLoaded service.running
[INFO    ] Running state [systemd-journald] at time 10:13:35.459823
[INFO    ] Executing state service.running for systemd-journald
[DEBUG   ] LazyLoaded cmd.run
[INFO    ] Executing command ['systemctl', 'status', 'systemd-journald.service', '-n', '0'] in directory '/root'

Case B:

test:
  pkg.installed:
    - name: virtual/service-manager
  service.running:
    - name: systemd-journald

[DEBUG   ] LazyLoaded service.running
[INFO    ] Running state [systemd-journald] at time 10:13:26.525498
[INFO    ] Executing state service.running for systemd-journald
[INFO    ] Executing command 'rc-update show' in directory '/root'

[stale[bot]]

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.

[kiemlicz]

Can someone confirm that masterless simply ignores the providers section from config e.g.

providers:
  service: service

?

[Ch3LL]

@kiemlicz what version of salt?

[kiemlicz]

latest 2018.3.3 Either I set provider in state or in config... it simply doesn't work (the salt-call --local is performed in docker container in my case and has no effect)

[stale[bot]]

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

[Ch3LL]

i'm not able to replicate this still. any chance you can share a sanitized version of the docker container you are using so i can try to replicate? Or a dockerfile with the setup

[kiemlicz]

Please take a look here:

 > docker pull kiemlicz/ambassador:ambassador-salt-masterless-run-640.1-failed
 > docker run -it --entrypoint /bin/bash  kiemlicz/ambassador:ambassador-salt-masterless-run-640.1-failed
root@1996e10f57cc:/# salt-call --local state.apply samba

It will run state samba from /srv/salt/base/samba/
This state contains service.running invocation. In this container the provider is overriden in state and in config (/etc/salt/minion.d/masterless.conf)

[stale[bot]]

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.