2015.8.0: Error writing to /var/log/salt/minion?
#27063
Comments
|
@lorengordon - if you do a sudo salt-call do you get the same results? |
|
Yes. I first saw the issue executing the command as a non-root user with sudo. I then switched to root and ran the command again, but the behavior was the same. |
jfindlay
added
Bug
|
@lorengordon, thanks for the report. I have tried to reproduce this on a linode CentOS 6 VM: [root@li1046-179 ~]# salt-call --local grains.get os
local:
CentOS
[root@li1046-179 ~]# salt --versions
Salt Version:
Salt: 2015.8.0
Dependency Versions:
Jinja2: unknown
M2Crypto: Not Installed
Mako: Not Installed
PyYAML: 3.11
PyZMQ: 14.5.0
Python: 2.6.6 (r266:84292, Jul 23 2015, 15:22:56)
RAET: Not Installed
Tornado: 4.2.1
ZMQ: 4.0.5
cffi: Not Installed
cherrypy: 3.2.2
dateutil: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
libnacl: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
python-gnupg: Not Installed
smmap: Not Installed
timelib: Not Installed
System Versions:
dist: centos 6.7 Final
machine: x86_64
release: 4.1.5-x86_64-linode61
system: CentOS 6.7 Final |
|
@lorengordon, is it possible for you to try with a new, clean VM? Thanks. |
|
This was a clean VM, but yes, I'll try a few AMIs in AWS to see what happens and try to figure out a pattern. |
|
@lorengordon - another thing to check for us: what are your permissions on both /var/log and /var/log/salt Second question is SELinux installed? |
|
Permissions were fine, I was otherwise able to create the directory with no problem. And I executed the install as root and ran salt-call as root. This was a fresh install and SELinux had not yet been configured in any way. And as I mentioned 2015.5.3 had no problem on the same system. But it was a custom AMI we create ourselves and we've run into oddball problems with custom AMIs before, so I will gladly try a few others that are more vanilla and report back. |
|
Oh, rereading the question, /var/log/salt did not exist until I created it manually. That was the problem that generated the warning message. Now, why didn't the directory exist or why didn't it get created on first access? That I don't know. |
|
Just tested with a generic Amazon Linux AMI (ami-0d4cfd66) and got the same behavior I reported. |
|
I can duplicate this by spinning up a vanilla instance like ami-0d4cfd66, and executing the below commands, which do nothing special, just setup the yum saltrepo and install salt. |
|
The issue here is that the The salt packages, in this case, should make sure those directories are created at installation time. So, as it is now, this is a packaging issue. |
|
@s0undt3ch How can I test that? I tried just setting |
|
Hmm... that should have worked.... I wonder if we're trying to write to the log file before verify env is executed.... |
jfindlay
added
Packaging
|
I forgot that we pulled out |
|
Re-assinging to @dmurphy18 per his request. |
|
Fixed the io operation error in #31544 |
cachedout
added
fixed-pls-verify
|
@lorengordon @ghost @jmo-learnosity I want to close this issue since testing with the latest release 2016.3.2 the issues with /var/log/salt/minion are resolved. Let me know if there are any objections to closing this issue. |
|
@dmurphy18, ok, I'll test 2016.3.2 with this in mind shortly. |
|
Yep, looks good now. /var/log/salt is created, and the error message is no longer reported. Closing, thanks! |
I just installed salt v2015.8.0 from the rpm hosted at https://repo.saltstack.com/yum, and it seems it's not creating
/var/log/saltbefore attempting to write to the minion log. This results in the warning message, "[WARNING ] Failed to open log file, do you have permission to write to /var/log/salt/minion?". I uninstalled and reinstalled, and got the same behavior. If I manually create the directory, the message goes away and the minion log is created.I removed v2015.8.0 and installed v2015.5.3 from epel, and it seems to create the directory the first time it attempts to write to the minion log.
The text was updated successfully, but these errors were encountered: