> On 14/06/2015 1:35 PM, Jamie Duncan wrote:
>> On Sat, Jun 13, 2015, 11:32 PM ToddAndMargo <[log in to unmask]
>> <mailto:[log in to unmask]>> 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 <[log in to unmask]
>>     <mailto:[log in to unmask]>
>>     > <mailto:[log in to unmask] <mailto:[log in to unmask]>>>
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: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897