Re: How does exec work with systemd?
On Wed, Sep 10, 2014 at 11:14:34AM -0400, Steve Litt wrote:
> On Wed, 10 Sep 2014 07:07:43 +0100
> Jonathan Dowland <jmtd@debian.org> wrote:
>
> > On Tue, Sep 09, 2014 at 09:19:19PM -0400, Steve Litt wrote:
> > > For years, I've been using exec to replace a shellscript with a
> > > binary executable. Something like this:
> > ...
> > > Is that behavior going to change with systemd?
> >
> > No.
>
> This is excellent news, because it means I can take a lot of my
> daemons out of systemd's control and put them in the control of djb's
> Daemontools, which, in my opinion, is a better way to run, control,
> and inspect daemons than any init system I've ever seen.
>
> The only thing is, Daemontools has no way of telling it which order to
> load things, so, for instance, I'll need to load the dns server
> before Dovecot and Apache, so the dns server will continue to be
> loaded by the init system.
>
> Daemontools is an outstanding system, and I think everyone should have
> at least a passing familiarity with it.
If you're not familiar with it, runit is a clone of daemontools
that is maintained in Debian.
Now, ordering system startup is actually incorrect: what you
need are guarantees that the services you depend on are
functioning at the time that you start them.
In a runit or daemontools run script, do a loop:
[ test for service availability -- a practical test is best, so
`dig @127.0.0.1 -t ns google.com` might be appropriate if you
need a resolving nameserver
if it fails, sleep for a second and retry
when it succeeds, run the daemon. ]
However, I think you'll find that for this particular case,
dovecot and apache don't actually need a local resolver, they
just work much faster with a local resolver. So don't make this
fragile: use an /etc/resolv.conf like this:
options timeout:3 attempts:1
nameserver 127.0.0.1
nameserver [something else you trust]
and then the ordering won't matter much.
-dsr-
Reply to: