mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 08:58:59 +00:00
130 lines
4.8 KiB
ReStructuredText
130 lines
4.8 KiB
ReStructuredText
===============================
|
|
Troubleshooting the Salt Minion
|
|
===============================
|
|
|
|
Running in the Foreground
|
|
=========================
|
|
|
|
A great deal of information is available via the debug logging system, if you
|
|
are having issues with minions connecting or not starting run the minion in
|
|
the foreground:
|
|
|
|
.. code-block:: bash
|
|
|
|
# salt-minion -l debug
|
|
|
|
Anyone wanting to run Salt daemons via a process supervisor such as `monit`_,
|
|
`runit`_, or `supervisord`_, should omit the ``-d`` argument to the daemons and
|
|
run them in the foreground.
|
|
|
|
.. _`monit`: http://mmonit.com/monit/
|
|
.. _`runit`: http://smarden.org/runit/
|
|
.. _`supervisord`: http://supervisord.org/
|
|
|
|
|
|
What Ports does the Minion Need Open?
|
|
=====================================
|
|
|
|
No ports need to be opened on the minion, as it makes outbound connections to
|
|
the master. If you've put both your Salt master and minion in debug mode and
|
|
don't see an acknowledgment that your minion has connected, it could very well
|
|
be a firewall interfering with the connection. See our :doc:`firewall
|
|
configuration </topics/tutorials/firewall>` page for help opening the firewall
|
|
on various platforms.
|
|
|
|
If you have netcat installed, you can check port connectivity from the minion
|
|
with the ``nc`` command:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ nc -v -z salt.master.ip.addr 4505
|
|
Connection to salt.master.ip.addr 4505 port [tcp/unknown] succeeded!
|
|
$ nc -v -z salt.master.ip.addr 4506
|
|
Connection to salt.master.ip.addr 4506 port [tcp/unknown] succeeded!
|
|
|
|
The `Nmap`_ utility can also be used to check if these ports are open:
|
|
|
|
.. code-block:: bash
|
|
|
|
# nmap -sS -q -p 4505-4506 salt.master.ip.addr
|
|
|
|
Starting Nmap 6.40 ( http://nmap.org ) at 2013-12-29 19:44 CST
|
|
Nmap scan report for salt.master.ip.addr (10.0.0.10)
|
|
Host is up (0.0026s latency).
|
|
PORT STATE SERVICE
|
|
4505/tcp open unknown
|
|
4506/tcp open unknown
|
|
MAC Address: 00:11:22:AA:BB:CC (Intel)
|
|
|
|
Nmap done: 1 IP address (1 host up) scanned in 1.64 seconds
|
|
|
|
If you've opened the correct TCP ports and still aren't seeing connections,
|
|
check that no additional access control system such as `SELinux`_ or
|
|
`AppArmor`_ is blocking Salt.
|
|
|
|
.. _`Nmap`: http://nmap.org/
|
|
.. _`SELinux`: https://en.wikipedia.org/wiki/Security-Enhanced_Linux
|
|
.. _`AppArmor`: http://wiki.apparmor.net/index.php/Main_Page
|
|
|
|
Using salt-call
|
|
===============
|
|
|
|
The ``salt-call`` command was originally developed for aiding in the development
|
|
of new Salt modules. Since then, many applications have been developed for
|
|
running any Salt module locally on a minion. These range from the original
|
|
intent of salt-call, development assistance, to gathering more verbose output
|
|
from calls like :mod:`state.highstate <salt.modules.state.highstate>`.
|
|
|
|
When initially creating your state tree, it is generally recommended to invoke
|
|
:mod:`state.highstate <salt.modules.state.highstate>` from the minion with
|
|
``salt-call``. This displays far more information about the highstate execution
|
|
than calling it remotely. For even more verbosity, increase the loglevel with
|
|
the same argument as ``salt-minion``:
|
|
|
|
.. code-block:: bash
|
|
|
|
# salt-call -l debug state.highstate
|
|
|
|
The main difference between using ``salt`` and using ``salt-call`` is that
|
|
``salt-call`` is run from the minion, and it only runs the selected function on
|
|
that minion. By contrast, ``salt`` is run from the master, and requires you to
|
|
specify the minions on which to run the command using salt's :doc:`targeting
|
|
system </topics/targeting/index>`.
|
|
|
|
Live Python Debug Output
|
|
========================
|
|
|
|
If the minion seems to be unresponsive, a SIGUSR1 can be passed to the process
|
|
to display what piece of code is executing. This debug information can be
|
|
invaluable in tracking down bugs.
|
|
|
|
To pass a SIGUSR1 to the minion, first make sure the minion is running in the
|
|
foreground. Stop the service if it is running as a daemon, and start it in the
|
|
foreground like so:
|
|
|
|
.. code-block:: bash
|
|
|
|
# salt-minion -l debug
|
|
|
|
Then pass the signal to the minion when it seems to be unresponsive:
|
|
|
|
.. code-block:: bash
|
|
|
|
# killall -SIGUSR1 salt-minion
|
|
|
|
When filing an issue or sending questions to the mailing list for a problem
|
|
with an unresponsive daemon, be sure to include this information if possible.
|
|
|
|
Multiprocessing in Execution Modules
|
|
====================================
|
|
|
|
As is outlined in github issue #6300, Salt cannot use python's multiprocessing
|
|
pipes and queues from execution modules. Multiprocessing from the execution
|
|
modules is perfectly viable, it is just necessary to use Salt's event system
|
|
to communicate back with the process.
|
|
|
|
The reason for this difficulty is that python attempts to pickle all objects in
|
|
memory when communicating, and it cannot pickle function objects. Since the
|
|
Salt loader system creates and manages function objects this causes the pickle
|
|
operation to fail.
|