On 30 August 2015 09:53:24 CEST, ToddAndMargo <[log in to unmask]> wrote:
>On 08/30/2015 12:23 AM, Tom H wrote:
>> On Sat, Aug 29, 2015 at 11:07 PM, ToddAndMargo
><[log in to unmask]> wrote:
>>> On 08/29/2015 06:04 PM, Nico Kadel-Garcia wrote:
>>>>
>>>> It's not necessary to put in rc.local: I just went through this
>with
>>>> someone else: that's what init scripts are for, to allow you to
>turn
>>>> on, and turn off, the relevant feature in a user legible fashion,
>even
>>>> in RHEL 7.
>>>
>>> Yes and no.  It kind of depends on what you are trying to do.
>>> I use rc.local as a grab bag of little miscellaneous one lines
>>> I like to do.
>>>
>>> I did create a init script for my firewall.
>>
>> Even if you just have one command, writing a systemd unit isn't much
>> more work than adding a line to rc.local.
>>
>> I have the following on my laptop in order to create a bridge for
>kvm:
>>
>> # cat /etc/systemd/system/tom-kvm-bridge0.service
>> [Unit]
>> Description=KVM Bridge0
>> After=network-online.target
>> After=tom-kvm-masquerade.service
>> Requires=tom-kvm-masquerade.service
>>
>> [Service]
>> Type=oneshot
>> ExecStart=/home/root/bin/p-kvm-bridge0-up.sh
>> ExecStop=/home/root/bin/p-kvm-bridge0-down.sh
>> RemainAfterExit=yes
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> ("/home/root" isn't root's homedir)
>>
>> It's less work than writing a sysvinit script so it's easier to avoid
>> using rc.local and it allows you to target the startup conditions
>more
>> accurately (and start/stop/restart that job on its own).
>Distributions
>> differ in their treatment of rc.local. If you were kicking off your
>> iptables rules via rc.local on SL, you'd be OK (I think). But if you
>> were doing so on Debian or Ubuntu, you'd be kicking them off after
>> bringing up the network because Debian adds the following fragment:
>>
>> # cat /lib/systemd/system/rc-local.service.d/debian.conf
>> [Unit]
>> # not specified by LSB, but has been behaving that way in Debian
>under SysV
>> # init and upstart
>> After=network-online.target
>>
>> # Often contains status messages which users expect to see on the
>console
>> # during boot
>> [Service]
>> StandardOutput=journal+console
>> StandardError=journal+console
>>
>
>
>Hi Tom,
>
>That is about 50 times more work than what I am doing.
>
>-T

Perhaps so when everything works. But once you need to start debugging when something stops working, using unit files gives you far better overview and control- through systemctl and journalctl.

Generally speaking, avoiding own hacks in favour of recommended distro methods usually gives you a far more stable and predictable installation where others more easily can step in when there are issues, as they don't need to all your non-standard tweaks.

-- 
mvh.

David Sommerseth