> On 14/06/2015 1:35 PM, Jamie Duncan wrote: >> On Sat, Jun 13, 2015, 11:32 PM ToddAndMargo <toddandma...@zoho.com >> <mailto:toddandma...@zoho.com>> wrote: >> >> On 06/13/2015 08:25 PM, Jamie Duncan wrote: >> > You define what each service needs or wants for it to be able to >> start. >> > Look at the .service files >> > >> > >> > On Sat, Jun 13, 2015, 11:23 PM ToddAndMargo <toddandma...@zoho.com >> <mailto:toddandma...@zoho.com> >> > <mailto:toddandma...@zoho.com <mailto:toddandma...@zoho.com>>> wrote: >> > >> > Hi All, >> > >> > /etc/rc/d/rc5.d with its numbered start points are being >> > phased out. In SL7, systemctl, what determines when things >> > start? >> > >> > Many thanks, >> > -T >> > >> >> # find /etc/systemd/system/ -iname \*.service | grep -i firewall >> /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service >> /etc/systemd/system/basic.target.wants/firewalld.service >> >> >> Is this it (firewalld.service)? >> [Unit] >> Description=firewalld - dynamic firewall daemon >> Before=network.target >> Before=libvirtd.service >> Before=NetworkManager.service >> Conflicts=iptables.service ip6tables.service ebtables.service >> >> So you tell it before what you want? Seems a bit confusing. >> Am I missing something? > > There are many options to allow it to be parallel. It's well documented > upstream and for RHEL. Time to hit the books!
What he's really saying is that there is no set order. There is no reliable order. There is no pre-determined order. What you do get is a setting that says "I will load service X before Y" - which it has to work out on every boot. It may or may not be the same order every time you boot - and depending on what is set where, it may even start services that are not specifically enabled if they are listed as dependencies. One good example is upowerd. Even if you have this disabled, it will still get started by other services in the boot process. Now you can argue until the cows come home as to if this is good or not - and I'll leave that to an academic argument. Before and After in the unit file can be abused - and you could end up very easily in a logic loop that is not possible. I'm not sure how it tries to deal with these cases - or if it just throws its hands up in the air and complains (verbally or silently). Consider the following: a.service: [Unit] Before b.service b.service: [Unit] Before a.service Now generally, if you only use distro supplied packages, this should be fine - however it does make things more difficult for the packager. -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature