mirror of
https://github.com/valitydev/salt.git
synced 2024-11-06 16:45:27 +00:00
57fba60eda
Previously, to make these run on Windows, I added the '.py'
extension. For example 'salt-master' => 'salt-master.py'
If this wasn't done, you would get an exception that looks like this
when spawning an addition process:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\salt\bin\lib\multiprocessing\forking.py",
line 380, in main
prepare(preparation_data)
File "C:\salt\bin\lib\multiprocessing\forking.py",
line 489, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named salt-master
Instead of adding the '.py' extension, I found another work-around that
seems to avoid the issue. The details are described in the file comments.
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
27 lines
948 B
Python
Executable File
27 lines
948 B
Python
Executable File
#!/usr/bin/env python
|
|
'''
|
|
This script is used to kick off a salt minion daemon
|
|
'''
|
|
|
|
from salt.scripts import salt_minion
|
|
from salt.utils import is_windows
|
|
from multiprocessing import freeze_support
|
|
|
|
|
|
if __name__ == '__main__':
|
|
if is_windows():
|
|
# Since this file does not have a '.py' extension, when running on
|
|
# Windows, spawning any addional processes will fail due to Python
|
|
# not being able to load this 'module' in the new process.
|
|
# Work around this by creating a '.pyc' file which will enable the
|
|
# spawned process to load this 'module' and proceed.
|
|
import os.path
|
|
import py_compile
|
|
cfile = os.path.splitext(__file__)[0] + '.pyc'
|
|
if not os.path.exists(cfile):
|
|
py_compile.compile(__file__, cfile)
|
|
# This handles the bootstrapping code that is included with frozen
|
|
# scripts. It is a no-op on unfrozen code.
|
|
freeze_support()
|
|
salt_minion()
|