Please make /etc/rc.local non-executable by default

[Jonathan de Boyne Pollard]

KatolaZ:

> I am not interested in a digression about who and why used or executed 
> rc.local
> [...]
> The important point is just: what is the benefit of removing +x from 
> /etc/rc.local?
>
This is not a digression, but *is* that point.  I just explained that to 
everything apart from the van Smoorenburg and systemd backwards 
compatibility mechanisms, it makes not one whit of difference, and 
changing it does not break things; those two backwards compatibility 
mechanisms differ from what they are aimed at being backwards compatible 
*with*, whose actual behaviour I explained.  Part of the additional 
benefit to those two, furthermore, was articulated by M. Triplett; the 
other part by M. Poettering.

What M. Poettering said applies to van Smoorenburg rc too, because it 
relates to service ordering.  I pointed out insserv, too, and how it 
interacts with the "99".  If you look at Debian bugs, you will find a 
fair number where an insserv action goes wrong, and the errors blame 
(unjustly much of the time) /etc/init.d/rc.local.  Bug #589238, for 
example, which is still open.  It's asked about regularly, with no 
resolution, outwith the Debian bug system, too.

* https://unix.stackexchange.com/questions/177819/

* https://unix.stackexchange.com/questions/190529/

Compare Debian bugs 758060, 626273, and 638032; and Ubuntu bugs 1537317, 
1548691, 1412101, 1482721, and 1487426 (and that's just for starters).  
The rc.local backwards compatibility mechanism gets the blame instead of 
the things that are the actual problems.  The systemd people made things 
so that the backwards compatibility mechanism is not included in the 
service ordering at all if /etc/rc.local is not executable.  van 
Smoorenburg rc would gain, modifying a misleading error message that has 
plagued bug reports on Debian, Ubuntu, and elsewhere and confused users 
for years, with a similar sort of removal based upon the x bit.