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