New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running SaltStack master with no init system repeatedly logs "could not determine init system " #48402

Closed
elsmorian opened this Issue Jul 2, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@elsmorian

elsmorian commented Jul 2, 2018

Description of Issue/Question

The info log of our salt master process are full of
Could not determine init system from command line: (/bin/bash /usr/local/bin/docker_entrypoint.sh run_saltmaster)
due to us running the salt-master process via su-exec, ie. without an init system.

I am aware of #46805 however it would be good if you could turn off salts attempts to get the init and put it in the grain system maybe?

Setup

A setup that does not use one of the init systems salt expects.

Steps to Reproduce Issue

Fire up salt master with the above

Versions Report

           Salt: 2017.7.0

Dependency Versions:
           cffi: 1.10.0
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.3
      gitpython: 2.1.9
          ioflo: Not Installed
         Jinja2: 2.9.6
        libgit2: 0.25.1
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: 2.18
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.25.0
         Python: 2.7.14 (default, Dec 14 2017, 15:51:29)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.3
        timelib: Not Installed
        Tornado: 4.5.2
            ZMQ: 4.2.2

System Versions:
           dist:
         locale: UTF-8
        machine: x86_64
        release: 4.4.0-128-generic
         system: Linux
        version: Not Installed
@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Jul 2, 2018

This logic is already occurring in the core grains . One solution could be to lower the logging level of that message to debug. Then a user would only see it with debug. Does that resolve your use case?

@Ch3LL Ch3LL added the Info Needed label Jul 2, 2018

@Ch3LL Ch3LL added this to the Blocked milestone Jul 2, 2018

@elsmorian

This comment has been minimized.

elsmorian commented Jul 2, 2018

Thanks for following up, we have tried that, but would really like the info level - If this was a lower level then could understand it, but according to https://docs.saltstack.com/en/latest/ref/configuration/logging/index.html#log-levels info is "Normal log information" which seems good, its just this persistent line!

As you say looks like it's from

'Could not determine init system from command line: (%s)',
- is there a way to custom set the init grain? I'm not quite sure why its being called on the master?

@Ch3LL

This comment has been minimized.

Contributor

Ch3LL commented Jul 3, 2018

you can see here: https://github.com/saltstack/salt/blob/v2018.3.2/salt/master.py#L1824

that we create a masterminion instance which is where we load the grains. My understanding is the master side uses the grains to load some modules required for some backends, so this is required. ping @saltstack/team-core is my understanding correct here?

@Ch3LL Ch3LL added Pending Discussion and removed Info Needed labels Jul 3, 2018

@gtmanfred

This comment has been minimized.

Contributor

gtmanfred commented Jul 3, 2018

The master loads grains because sometimes the grains are used for modules, and those modules can be used in orchestration files, or rendering pillars, sometimes you want to query mysql in your pillar.sls files.

It is just an info log, if it does not apply to your usecase, then ignore it, we default to log_level: warning for a reason, so that all that other "info" stuff isn't in there.

Though, i don't have a personal problem with change that particular one to a debug log level.

@terminalmage

This comment has been minimized.

Member

terminalmage commented Jul 5, 2018

I agree with @gtmanfred. I opened #48441 to change the loglevel to debug for this.

@elsmorian

This comment has been minimized.

elsmorian commented Jul 5, 2018

Thanks for the explanation and for the changing to a debug @gtmanfred and @terminalmage thats very helpful!

@rallytime

This comment has been minimized.

Contributor

rallytime commented Jul 5, 2018

Closed via #48441

@rallytime rallytime closed this Jul 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment