Salt: service.restart salt-minion fails on Ubuntu 14.04.5 LTS

[githubcdr]

This fails

salt-call service.restart salt-minion -l all

[DEBUG   ] LazyLoaded file.touch
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/cli/caller.py", line 197, in call
    ret['return'] = func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/salt/modules/daemontools.py", line 135, in restart
    if stop(name) and start(name):
  File "/usr/lib/python2.7/dist-packages/salt/modules/daemontools.py", line 90, in stop
    __salt__['file.touch']('{0}/down'.format(_service_path(name)))
  File "/usr/lib/python2.7/dist-packages/salt/modules/file.py", line 2698, in touch
    raise CommandExecutionError(exc.strerror)
CommandExecutionError: No such file or directory
Error running 'service.restart': No such file or directory

Setup

Default Ubuntu 14.04.5 LTS installation

Versions Report

Salt Version:
           Salt: 2016.3.4

Dependency Versions:
           cffi: 0.8.6
       cherrypy: Not Installed
       dateutil: 1.5
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: 1.3.7
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: 1.4.3
       M2Crypto: Not Installed
           Mako: 0.9.1
   msgpack-pure: 0.1.3
 msgpack-python: 0.4.6
   mysql-python: 1.2.5
      pycparser: 2.10
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
   python-gnupg: Not Installed
         PyYAML: 3.10
          PyZMQ: 15.2.0
           RAET: 0.6.3
          smmap: 0.8.2
        timelib: 0.2.4
        Tornado: 4.2.1
            ZMQ: 4.1.2

System Versions:
           dist: Ubuntu 14.04 trusty
        machine: x86_64
        release: 3.13.0-100-generic
         system: Linux
        version: Ubuntu 14.04 trusty

[Ch3LL]

@githubcdr i'm not able to replicate this. How did you install salt?

[PChambino]

Something similar happened to me that I believe is related. Replication steps:

1. Setup an Ubuntu 14.04 installation.
2. Install salt 2016.3.4
3. Run: sudo salt-call service.get_all
   
   
   
   • Outputs list of services.
   
   
4. Install daemontools: sudo apt-get install daemontools
5. Run: sudo salt-call service.get_all
   
   
   
   • Outputs: Error running 'service.get_all': Could not find service directory.
   
   

I believe the problem appeared due to this commit 9451141b3f7c6bbd97979c16c8126d422da89df5
Maybe the __virtual__ function should check if SERVICE_DIR is set?

The quick fix is to append this to your minion conf file:

providers:
  service: upstart

https://docs.saltstack.com/en/latest/ref/modules/index.html#module-provider-override

[Ch3LL]

@PChambino thanks for the replication steps here. Looks like you also go the issue resolved. @githubcdr did you want to check teh fix in #37748 and se if that works for you as well?

[meggiebot]

@githubcdr were you able to validate the fix for this?

[githubcdr]

Hi,

I run Ubuntu 14.4 LTS which is upstart based, I also installed Qmail which is daemontools based. This creates a conflict in Salt for the service module.

salt-call service.get_all
local:
    - qmail-send
    - qmail-smtpd
    - qmail-smtpd-auth

After changing the virtualname in daemontools.py to daemontools for example things are working. I think the module overrides the upstart service module.

__virtualname__ = 'daemontools'

The "providers" solutions is a workaround that works, but the fix does not work in my case.

[meggiebot]

@githubcdr Got it, thank you for testing. I will remove the fixed label.

[tankywoo]

Hello, I ran into the same problem as @githubcdr commented, after I upgrade my salt-minion to 2016.11.1

View the source code and found default service virtualname is override by commid id #36330 ,which changes the daemontools service's __virtualname__ to service, this cause it preload to upstart and be default service.

such as exim4 installed by apt in my local host:

$ salt-call service.available exim4
local:
    False

system wide service should be the the default service provider, and daemontools as a third-party service should use provider, and not override default service.

the solution is rename __virtualname__ = 'service' to __virtualname__ = 'daemontools'

@rallytime @Ch3LL

[rallytime]

Thanks for the conversation here. @githubcdr and @tankywoo can you give #37748 a try and confirm that it fixes this issue for you?

[githubcdr]

Hi @rallytime, #37748 has been tested already in this thread?

[rallytime]

@githubcdr I suppose that is what I am confused about. There are links in this thread to #37748, but I didn't see anyone specifically saying they had tried that fix and it worked or not. I only saw links to the PR that broke it. Another user mentioned in the comments on #37748 that it fixed the issue for them, but I am not sure where we stand here.

[githubcdr]

There are 2 issues here, one with the specific daemontools module and the main issue here that makes Salt think a system running daemontools AND systemd gets detected as daemontools only. #37748 is related to the first issue.

[rallytime]

@githubcdr Ah, OK. I see that now. Thanks for the clarification and apologies for the confusion.

[tankywoo]

Hi @rallytime , @githubcdr , As I mentioned in my comment, #36330 first change __virtualname__ to service for daemontools, which cause the problem.

[rallytime]

@githubcdr and @tankywoo please see #38587.

[cachedout]

Closed via #38587

[tankywoo]

@rallytime 👍