Open cruscio opened 6 years ago
Are you seeing this with linux minions as well or only windows minions?
Hey @gtmanfred - Just tested it on a linux minion and did not see the same behavior.
Salt Version:
Salt: 2017.7.1
Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 2.4.2
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.8
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: 1.0.3
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.12 (default, Nov 19 2016, 06:48:10)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.2.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4
System Versions:
dist: Ubuntu 16.04 xenial
locale: UTF-8
machine: x86_64
release: 4.4.0-62-generic
system: Linux
version: Ubuntu 16.04 xenial
Yes, the problem with windows is there is no equivalent to os.fork
which linux uses to create the new process, which gives the exact same namespace from the point where it was forked.
For windows, since there is no memory forking equivalent, so we have to reinitialize the process each time a new windows minion process is create, and I think that wherever this is loaded, it is causing the random delay to happen.
@twangboy @UtahDave can one of yall take a look at this, and see if we could pass a variable to init on the Minion class to let it know that this is a "forked" process, and shouldn't do the sleep?
Thanks, Daniel
@gtmanfred This may be a big part of the slow down we're seeing on Windows minions.
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.
This is still occurring on Windows hosts with the 2019.2 minion. It's impacting our workflows. Can it get a little love?
@twangboy Does this need some further work to get your PR merged in?
Thank you for updating this issue. It is no longer marked as stale.
Thank you for updating this issue. It is no longer marked as 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.
Thank you for updating this issue. It is no longer marked as stale.
Hi, this is still an issue (at least on Windows), 3004.2.
2022-10-13 19:07:39,285 [salt.minion :1296][INFO ][4676] Minion sleeping for 19 seconds due to configured startup_delay between 0 and 20 seconds 2022-10-13 19:07:44,371 [salt.minion :1296][INFO ][4704] Minion sleeping for 14 seconds due to configured startup_delay between 0 and 20 seconds
This one should get fixed, causing problems with minion responses
Description of Issue/Question
Windows minion applies random_startup_delay configuration value to jobs executed by the master.
Setup
Minion config: log_level: debug log_level_logfile: debug random_startup_delay: 120
Steps to Reproduce Issue
Run
salt '*' test.ping
multiple times on the masterActual Outcome:
Expected Outcome:
Versions Report
Master
Minion