Join GitHub today
Running SaltStack master with no init system repeatedly logs "could not determine init system " #48402
Description of Issue/Question
The info log of our salt master process are full of
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?
A setup that does not use one of the init systems salt expects.
Steps to Reproduce Issue
Fire up salt master with the above
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
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
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?
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.