[salt-users] salt-run manage.status IOError on jid, dmidecode warning. How to identify related minion?

On Fri, Aug 7, 2015 at 4:00 PM, Jeff Kowalczyk wrote:

Using salt-master 2015.5.3+ds-1trusty1 on Ubuntu 14.04.2 usining salt-run
manage.status raises an IOError on a jid cache access, repeated twice in
output. Is the job id related to salt master's call to salt-run, or a
particular minion, and if so, how to tell which one?

Also raised is a dmidecode warning, likely due to use of a dedicated salt
user (member of groups salt, adm, sudo) instead of root. Is there a way to
tell whether the master or which minion is failing in attempts to access
dmidecode? Are there configuration options to either limit what dmidecode
attempts to query such that non-root works, or a way to suppress dmidecode
queries despite it being found in the path?

salt@salt:~$ salt-run manage.status
down:
- host01
- host09
up:
- host02
- host03
- host04
- host05
- host06
- host07
- host08
- host10
- host11
[WARNING ] Although 'dmidecode' was found in path, the current user
cannot execute it. Grains output might not be accurate.
[ERROR ] An un-handled exception was caught by salt's global exception
handler:
IOError: [Errno 2] No such file or directory: '/var/cache/salt/master/jobs
/1e/cba441fe957bc61f8b192f2dc03c6f/jid'
Traceback (most recent call last):
File "/usr/bin/salt-run", line 10, in <module>
salt_run()
File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 250, in
salt_run
client.run()
File "/usr/lib/python2.7/dist-packages/salt/cli/run.py", line 54, in run
runner.run()
File "/usr/lib/python2.7/dist-packages/salt/runner.py", line 166, in run
False) # Don't daemonize
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 381,
in _proc_function
return self.low(fun, low)
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 336,
in low
mminion=self.mminion,
File "/usr/lib/python2.7/dist-packages/salt/utils/job.py", line 51, in
store_job
mminion.returners[jidstore_fstr](False, passed_jid=load['jid'])
File "/usr/lib/python2.7/dist-packages/salt/returners/local_cache.py",
line 124, in prep_jid
with salt.utils.fopen(os.path.join(jid_dir_, 'jid'), 'wb+') as fn_:
File "/usr/lib/python2.7/dist-packages/salt/utils/__init__.py", line
1045, in fopen
fhandle = open(*args, **kwargs)
IOError: [Errno 2] No such file or directory:
'/var/cache/salt/master/jobs/1e/cba441fe957bc61f8b192f2dc03c6f/jid'
Traceback (most recent call last):
File "/usr/bin/salt-run", line 10, in <module>
salt_run()
File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 250, in
salt_run
client.run()
File "/usr/lib/python2.7/dist-packages/salt/cli/run.py", line 54, in run
runner.run()
File "/usr/lib/python2.7/dist-packages/salt/runner.py", line 166, in run
False) # Don't daemonize
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 381,
in _proc_function
return self.low(fun, low)
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 336,
in low
mminion=self.mminion,
File "/usr/lib/python2.7/dist-packages/salt/utils/job.py", line 51, in
store_job
mminion.returners[jidstore_fstr](False, passed_jid=load['jid'])
File "/usr/lib/python2.7/dist-packages/salt/returners/local_cache.py",
line 124, in prep_jid
with salt.utils.fopen(os.path.join(jid_dir_, 'jid'), 'wb+') as fn_:
File "/usr/lib/python2.7/dist-packages/salt/utils/__init__.py", line
1045, in fopen
fhandle = open(*args, **kwargs)
IOError: [Errno 2] No such file or directory:
'/var/cache/salt/master/jobs/1e/cba441fe957bc61f8b192f2dc03c6f/jid'

Thank you for any suggestions to eliminate these errors. I'll be glad to
file in the tracker if either of these look like a valid issue.

Jeff


--
You received this message because you are subscribed to the Google Groups
"Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Tuesday, August 18, 2015 at 12:06:29 PM UTC-7, basepi wrote:

Are you running salt as the `salt` user or as root? `salt-run` should be
run as the same user as salt. Additionally, that user needs to have write
access to /var/cache/salt and everything underneath. It seems like there
might be an issue there and that's why the file it not being found later
on, because it wasn't successfully created in the first place.

--
Colton Myers
Core Engineer, SaltStack
@basepi on Twitter/Github/IRC

On Fri, Aug 7, 2015 at 4:00 PM, Jeff Kowalczyk <jeff.ko...@gmail.com
<javascript:>> wrote:

On Friday, October 30, 2015 at 3:45:50 PM UTC-7, Jeff Kowalczyk wrote:

I run both salt master and minions as user salt, not root.

There is a file and a directory under /var/cache/salt that are still owned
by root. Should I change ownership of both?

salt@salt:~$ find /var/cache/salt \! -user salt -ls

70258312 4 drwxr-xr-x 3 root root 4096 Jul 9 2014
/var/cache/salt
70254637 4 -r-------- 1 root root 76 Oct 29 07:39
/var/cache/salt/master/.root_key

Jeff

On Oct 30, 2015, at 5:19 PM, Jeff Kowalczyk wrote:

As follow up, I did go ahead and ensure salt:salt owned /var/cache/salt, and everything else under /var/cache/salt, then restarted salt master. The exceptions still occur.

I note that .root_key gets recreated with ownership root:root, not salt:salt.

salt@salt01:~$ find /var/cache/salt \! -user salt -ls
70254637 4 -r-------- 1 root root 76 Oct 30 23:00 /var/cache/salt/master/.root_key


On Friday, October 30, 2015 at 3:45:50 PM UTC-7, Jeff Kowalczyk wrote:
I run both salt master and minions as user salt, not root.

There is a file and a directory under /var/cache/salt that are still owned by root. Should I change ownership of both?

salt@salt:~$ find /var/cache/salt \! -user salt -ls
70258312 4 drwxr-xr-x 3 root root 4096 Jul 9 2014 /var/cache/salt
70254637 4 -r-------- 1 root root 76 Oct 29 07:39 /var/cache/salt/master/.root_key

Jeff

On Tuesday, August 18, 2015 at 12:06:29 PM UTC-7, basepi wrote:
Are you running salt as the `salt` user or as root? `salt-run` should be run as the same user as salt. Additionally, that user needs to have write access to /var/cache/salt and everything underneath. It seems like there might be an issue there and that's why the file it not being found later on, because it wasn't successfully created in the first place.

--
Colton Myers
Core Engineer, SaltStack
@basepi on Twitter/Github/IRC

On Fri, Aug 7, 2015 at 4:00 PM, Jeff Kowalczyk wrote:
Using salt-master 2015.5.3+ds-1trusty1 on Ubuntu 14.04.2 usining salt-run manage.status raises an IOError on a jid cache access, repeated twice in output. Is the job id related to salt master's call to salt-run, or a particular minion, and if so, how to tell which one?

Also raised is a dmidecode warning, likely due to use of a dedicated salt user (member of groups salt, adm, sudo) instead of root. Is there a way to tell whether the master or which minion is failing in attempts to access dmidecode? Are there configuration options to either limit what dmidecode attempts to query such that non-root works, or a way to suppress dmidecode queries despite it being found in the path?

salt@salt:~$ salt-run manage.status
down:
- host01
- host09
up:
- host02
- host03
- host04
- host05
- host06
- host07
- host08
- host10
- host11
[WARNING ] Although 'dmidecode' was found in path, the current user cannot execute it. Grains output might not be accurate.
[ERROR ] An un-handled exception was caught by salt's global exception handler:
IOError: [Errno 2] No such file or directory: '/var/cache/salt/master/jobs/1e/cba441fe957bc61f8b192f2dc03c6f/jid'
Traceback (most recent call last):
File "/usr/bin/salt-run", line 10, in <module>
salt_run()
File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 250, in salt_run
client.run()
File "/usr/lib/python2.7/dist-packages/salt/cli/run.py", line 54, in run
runner.run()
File "/usr/lib/python2.7/dist-packages/salt/runner.py", line 166, in run
False) # Don't daemonize
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 381, in _proc_function
return self.low(fun, low)
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 336, in low
mminion=self.mminion,
File "/usr/lib/python2.7/dist-packages/salt/utils/job.py", line 51, in store_job
mminion.returners[jidstore_fstr](False, passed_jid=load['jid'])
File "/usr/lib/python2.7/dist-packages/salt/returners/local_cache.py", line 124, in prep_jid
with salt.utils.fopen(os.path.join(jid_dir_, 'jid'), 'wb+') as fn_:
File "/usr/lib/python2.7/dist-packages/salt/utils/__init__.py", line 1045, in fopen
fhandle = open(*args, **kwargs)
IOError: [Errno 2] No such file or directory: '/var/cache/salt/master/jobs/1e/cba441fe957bc61f8b192f2dc03c6f/jid'
Traceback (most recent call last):
File "/usr/bin/salt-run", line 10, in <module>
salt_run()
File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 250, in salt_run
client.run()
File "/usr/lib/python2.7/dist-packages/salt/cli/run.py", line 54, in run
runner.run()
File "/usr/lib/python2.7/dist-packages/salt/runner.py", line 166, in run
False) # Don't daemonize
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 381, in _proc_function
return self.low(fun, low)
File "/usr/lib/python2.7/dist-packages/salt/client/mixins.py", line 336, in low
mminion=self.mminion,
File "/usr/lib/python2.7/dist-packages/salt/utils/job.py", line 51, in store_job
mminion.returners[jidstore_fstr](False, passed_jid=load['jid'])
File "/usr/lib/python2.7/dist-packages/salt/returners/local_cache.py", line 124, in prep_jid
with salt.utils.fopen(os.path.join(jid_dir_, 'jid'), 'wb+') as fn_:
File "/usr/lib/python2.7/dist-packages/salt/utils/__init__.py", line 1045, in fopen
fhandle = open(*args, **kwargs)
IOError: [Errno 2] No such file or directory: '/var/cache/salt/master/jobs/1e/cba441fe957bc61f8b192f2dc03c6f/jid'

Thank you for any suggestions to eliminate these errors. I'll be glad to file in the tracker if either of these look like a valid issue.

Jeff

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.