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