mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 17:09:03 +00:00
84c6b62005
Added an nmap example for checking if ports are open, removed some redundant wording, and reworded other parts to be more concise.
117 lines
4.2 KiB
ReStructuredText
117 lines
4.2 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.
|