rc.local not start at the boot
Ed Greshko
ed.greshko at greshko.com
Fri Oct 31 22:14:31 UTC 2014
On 11/01/14 03:01, Joe Zeff wrote:
> On 10/31/2014 05:49 AM, Angelo Moreschini wrote:
>> SELINUX=permissive =--> didn't work
>>
>> setsebool -P rsync_full_access 1 =--> didn't work too
>
> Therefor SELinux isn't involved.
Yes, as it now stands selinux is not involved.
I would like to mention that I actually have had 2 test environments during this thread.
The first time that I "fixed" it I hadn't looked to see if there was a AVC. Even though there were no error messages I considered it may be related to file permissions or ownership. So, I called the script containing the rsync using "su -c" to change to the user "programmers". This fixed the problem. It also, resulted in being able to remove the"su -c". This was a head scratcher for me.....but I didn't want to mention it he so as not to confuse things. But, looking back, I suspect, running with the "su -c" may have had the effect of changing the selinux context on the directory being written by rsync.
It was only in the second, newly built, environment that I spotted the AVC and fixed it as I mentioned.
Now, all that being said, I think something has changed in the OPs environment. If you look back on all the various messages and other threads you'll notice that he first reported this on 10/29.
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Tue 2014-10-28 17:07:57 IST; 3h 2min ago
Process: 877 ExecStart=/etc/rc.d/rc.local start (code=exited, status=3)
notice the exit status=3.
Most recently he reported this....
rc-local.service - /etc/rc.d/rc.local Compatibility
Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
Active: failed (Result: exit-code) since Fri 2014-10-31 20:43:44 IST; 2min 10s ago
Process: 891 ExecStart=/etc/rc.d/rc.local start (code=exited, status=1/FAILURE)
The exit status is now status=1/FAILURE.
Something has changed.
If I were doing the troubleshooting I would go back and fix the scripts to send their logging information to files in /tmp to see if they are now generating usable error messages.
--
If you can't laugh at yourself, others will gladly oblige.
More information about the users
mailing list