mirror of
https://github.com/valitydev/salt.git
synced 2024-11-08 17:33:54 +00:00
42c5058a1e
Closes #33627
155 lines
6.0 KiB
ReStructuredText
155 lines
6.0 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. Tools like `tcptraceroute`_ can also be used
|
|
to determine if an intermediate device or firewall is blocking the needed
|
|
TCP ports.
|
|
|
|
.. _`Nmap`: http://nmap.org/
|
|
.. _`SELinux`: https://en.wikipedia.org/wiki/Security-Enhanced_Linux
|
|
.. _`AppArmor`: http://wiki.apparmor.net/index.php/Main_Page
|
|
.. _`tcptraceroute`: http://linux.die.net/man/1/tcptraceroute
|
|
|
|
.. _troubleshooting-minion-salt-call:
|
|
|
|
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.apply <salt.modules.state.apply_>`.
|
|
|
|
When initially creating your state tree, it is generally recommended to invoke
|
|
highstates by running :mod:`state.apply <salt.modules.state.apply_>` directly
|
|
from the minion with ``salt-call``, rather than remotely from the master. This
|
|
displays far more information about the execution than calling it remotely. For
|
|
even more verbosity, increase the loglevel using the ``-l`` argument:
|
|
|
|
.. code-block:: bash
|
|
|
|
# salt-call -l debug state.apply
|
|
|
|
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.
|
|
|
|
Salt Minion Doesn't Return Anything While Running Jobs Locally
|
|
==============================================================
|
|
|
|
When a command being run via Salt takes a very long time to return
|
|
(package installations, certain scripts, etc.) the minion may drop you back
|
|
to the shell. In most situations the job is still running but Salt has
|
|
exceeded the set timeout before returning. Querying the job queue will
|
|
provide the data of the job but is inconvenient. This can be resolved by
|
|
either manually using the ``-t`` option to set a longer timeout when running
|
|
commands (by default it is 5 seconds) or by modifying the minion
|
|
configuration file: ``/etc/salt/minion`` and setting the ``timeout`` value to
|
|
change the default timeout for all commands, and then restarting the
|
|
salt-minion service.
|
|
|
|
.. note::
|
|
|
|
Modifying the minion timeout value is not required when running commands
|
|
from a Salt Master. It is only required when running commands locally on
|
|
the minion.
|