Solved Starting daemons in a particular order in rc.conf?

I've been trying to speed up the booting of one of our DNS & monitoring servers, as it takes an exceptionally long time. Looking at it while it boots, it seems to hang for a long time when starting smokeping. Looking even closer, I noticed unbound starts, then smokeping, and then nsd. The problem here (I suspect) is that as it boots, smokeping is trying to resolve the couple hundred hostnames of all the hosts its monitoring, and it first queries itself--running unbound, but not yet nsd. Unbound has no way to query the stub zone since nsd isn't running, so eventually it falls back to the backup DNS server, that's already up and running. However, this takes a long time, and thus, it takes a very long time for smokeping to start.

I'm sure there are other ways a similar situation can develop with other daemons/services, but what I'm wondering is, what's the pedantic way to deal with this sort of situation? Or failing that, what way do you recommend? I just need some way to have daemon 'x' (smokeping, in this instance) require the other daemons 'y' and 'z' (unbound and nsd) to be started first. While I can think of several ways to do this, I'd like to do it in the most appropriate manner.
 
Okay, so the best way to do this is to edit the rc.d scripts to include the appropriate lines for rcorder? My only concern is that the scripts are installed by their associated ports, and editing them will then cause them not to be removed/updated with removal/updating of the port. That said, this does sound like the best way to address the issue.

Edit: Found the relevant section of the handbook. I suppose the best way is to add some meta-tag, like DNS, and have any service that might need to resolve names REQUIRE it.
 
This is one area where FreeBSD could improve alot, it's not acceptable that a customization such as this requires you to directly edit the rc(8) scripts.
 
While OpenRC looks like it would work, using it feels like wielding a sledgehammer when all you need is a scalpel. Gutting and replacing the entire rc system seems like it should be a last resort, and not the first response. I'd prefer to see a few changes to the rc in the base system instead, and for the time being I've just edited the scripts so they should run in the correct order.

That said, it does look like it has a few neat features, like starting daemons in parallel, and the overrides you mention.
 
I was mainly just linking that to point out that it should be possible to add such functionality to the existing rc system, and providing a configuration example of what it looks like for OpenRC. I've also struggled with getting iscsi related services to start in the correct order after and before other services for example which have caused me myself to resort to hand editing rc.d scripts. So it would be nice to have a feature like this to control order without having to touch base system files.
 
You can prefix the scripts with a number if you want the scripts to be executed in a specific order - see the rc() man page. Here's the clip:

Code:
         The scripts within each directory are executed in lexicographical
         order.  If a specific order is required, numbers may be used as a
         prefix to the existing filenames, so for example 100.foo would be
         executed before 200.bar; without the numeric prefixes the opposite
         would be true.
 
You can prefix the scripts with a number
By default is it in reverse lexicographical order? That seems more like what I'm seeing, as otherwise nsd should start before smokeping, and unbound would start last, but that's the reverse of what I'm seeing.

Anyway, I did modify the script to use REQUIRES DNS and the necessary counterpart in unbound, and set nsd to be BEFORE unbound. Now the machine starts up much more quickly!

Edit: Well I thought that would solve the problem, but the rc.d scripts get overwritten when updating the port, and even if you don't update it pollutes the daily status email with checksum mismatches. I think the best way to avoid the problem more permanently is (unfortunately) just use rc.local (and put in, e.g. service nsd onestart) to start things in the order you really want.
 
Last edited:
Back
Top