Troubleshooting grains and pillars

While writing grains and pillars, you may encounter some difficulties. Let's take a look at the most common problems you might have.

Dynamic grains not showing up

You may find that when you issue a grains.items command from the Master, your dynamic grains aren't showing up. This can be difficult to track down, because grains are evaluated on the Minion, and any errors aren't likely to make it back over the wire to you.

When you find that dynamic grains aren't showing up as you expect, it's usually easiest to log in to the Minion directly to troubleshoot. Open up a shell and try issuing a salt-call command to see if any errors manifest themselves. If they don't immediately, try adding --log-level=debug to your command to see if any errors have been hiding at that level. Using a trace log level might also be necessary.

External pillars not showing up

These can be a little more difficult to pick out. Using salt-call is effective in finding errors in grains, because all of the code can be executed without starting up or contacting a service. But pillars come from the Master, unless you're running salt-call in local mode.

If you are able to install your external pillar code on a Minion for testing, then the steps are the same as for checking for grains errors. But if you find yourself in a situation where the Master's environment cannot be duplicated on a Minion, you will need to use a different tactic.

Stop the salt-master service on the Master, and then start it back up in the foreground, with a debug log level:

# salt-master --log-level debug

Then open up another shell and check the pillars for an affected Minion:

# salt <minionid> pillar.items

Any errors in the pillar code should manifest themselves in the window with salt-master running in the foreground.