Upstart job for BIND9

[Alexander Gurvitz]

Hello.

I'm trying to run a bind9 from an upstart job instead of an init.d script.

I'm a bit confused if I should "expect fork" or "expect daemon". It seems

to work with "expect fork", though somehow I don't feel convinced.

(Upstart must know how the daemon forks - if it forks once,

"expect fork" should be specified, and if a daemon forks twice,

it should be "expect daemon". Then upstart will wait for that forkings and

will monitor the final PID).

Thanks in advance,

Alexander Gurvitz,

net-me.net

P.S My /etc/init/bind.conf:

start on runlevel [2345]

stop on runlevel [!2345]

pre-start script

        # dirs under /var/run can go away on reboots.

        mkdir -p /var/run/named

        chmod 775 /var/run/named

        chown root:bind /var/run/named >/dev/null 2>&1 || true

end script

exec /usr/sbin/named -u bind

pre-stop exec rndc stop -p

post-stop exec logger -p user.warning -t upstart-bind "bind stopped"

expect fork

respawn

respawn limit 3 10

kill timeout 30

console none

[Carsten Strotmann]

Hello Alexander,

Alexander Gurvitz <al...@net-me.net> writes:

> Hello.
>
> I'm trying to run a bind9 from an upstart job instead of an init.d
> script.
> I'm a bit confused if I should "expect fork" or "expect daemon". It
> seems
> to work with "expect fork", though somehow I don't feel convinced.
>
> (Upstart must know how the daemon forks - if it forks once,
> "expect fork" should be specified, and if a daemon forks twice,
> it should be "expect daemon". Then upstart will wait for that forkings
> and
> will monitor the final PID).
>

my experience is:

named starts as user "root", forks a new instance as the non-privileged
user (if started as a non-privileged user like "bind" or "named"). The
original instance (running as root) stays until the non-privileged
instance has successfully loaded all zones, then it the original
instance terminates, and only the non-privileged process continues to
run.

If you have succeeded with the upstart job, would you share it with us
(it would be useful as a contribution to the BIND distibution as well)?

-- Carsten

[Alexander Gurvitz]

Carsten,

The script in my original question (it's in the P.S. at the bottom of my first mail) seem to work for me. It does not cover all the extra logic of the ubuntu default init.d/bind9, but I personally don't need that (ubuntu script may update resolv.conf, and also checks if there's a network available).

But now I realised that it's all much simpler. "named -f" runs bind in the foreground (does not daemonise) and that's just what upstart needs. Here's my new upstart job file, place it to /etc/init/bind.conf (I can't decide which one is better: bind.conf, bind9.conf or named.conf :)

#UPSTART JOB FOR BIND9

start on runlevel [2345]

stop on runlevel [!2345]

pre-start script

# dirs under /var/run can go away on reboots.

mkdir -p /var/run/named

chmod 775 /var/run/named

chown root:bind /var/run/named >/dev/null 2>&1 || true

end script

#Add bind command-line options below

exec /usr/sbin/named -f -u bind

pre-stop exec rndc stop

post-stop exec logger -p user.warning -t upstart-bind "bind stopped"

respawn

respawn limit 3 10

kill timeout 30

console none

#END

It will run bind on runlevels 2345, stop bind on other runlevels, but the most important - respawn it once it stops with one it's famous assertion failures :). It also logs a warning to syslog when bind closes (I use something like that to send me an email).

If someone wants to use the job, here's some instructions: 1. don't forget to disable the init.d script, or you may end up with two conflicting nameds - the easiest way is sudo chmod -x /etc/init.d/bind9 . 2. As with any upstart job, to stop bind you now do "stop bind", to start - "start bind", and there's also "restart bind". If you have your fancy stuff in /etc/defaults/bind9, just add at to the end of the "exec" line. 

It seems to work for me, but I can't say it's really tested. Comments and improvements are greatly appreciated.

Alex,

net-me.net

[Carsten Strotmann]

Hello Alexander,

Alexander Gurvitz <al...@net-me.net> writes:

> Carsten,
>
> The script in my original question (it's in the P.S. at the bottom of
> my first mail) seem to work for me.

Ahh, thanks, my Emacs was hiding that :)

> (I can't decide which one is better: bind.conf, bind9.conf or
> named.conf :)

I would vote for "bind9-upstart.conf".

"named.conf" is already the default name for the BIND 9 configuration

"bind.conf" is not specific once BIND 10 will be used on the same
machine.


-- Carsten

[Matus UHLAR - fantomas]

On 29.11.12 14:03, Alexander Gurvitz wrote:
>It will run bind on runlevels 2345, stop bind on other runlevels, but the
>most important - respawn it once it stops with one it's famous assertion
>failures :).

famous assertion failures? What system do you run the BIND on? Shouldn't you
better upgrade to version that has no famous assertion failures?


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux IS user friendly, it's just selective who its friends are...

[Alexander Gurvitz]

On Thu, Nov 29, 2012 at 7:25 PM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:

famous assertion failures? What system do you run the BIND on? Shouldn't you

better upgrade to version that has no famous assertion failures?

 

Well, of course it's extremely exaggerated, sorry if I offended someone. But crashes may happen, actually I started to play with upstart after named stopped once on our production system (it's not an outdated version). I think it's a good idea to make it respawn.

Alex

[Noel Butler]

On Thu, 2012-11-29 at 13:35 +0100, Carsten Strotmann wrote:

Hello Alexander,

Alexander Gurvitz <al...@net-me.net

> writes:

> Carsten,
>
> The script in my original question (it's in the P.S. at the bottom of
> my first mail) seem to work for me. 

Ahh, thanks, my Emacs was hiding that :)


> (I can't decide which one is better: bind.conf, bind9.conf or
> named.conf :)

I would vote for "bind9-upstart.conf".

"named.conf" is already the default name for the BIND 9 configuration

You would probably get better help for ubuntu-specific things on a ubuntu mailing list.

[Matus UHLAR - fantomas]

>On Thu, Nov 29, 2012 at 7:25 PM, Matus UHLAR - fantomas
><uh...@fantomas.sk>wrote:
>
>> famous assertion failures? What system do you run the BIND on? Shouldn't
>> you
>> better upgrade to version that has no famous assertion failures?

On 29.11.12 20:50, Alexander Gurvitz wrote:
>Well, of course it's extremely exaggerated, sorry if I offended someone.
>But crashes may happen, actually I started to play with upstart after named
>stopped once on our production system (it's not an outdated version). I
>think it's a good idea to make it respawn.

I don't think it's wise to respawn named without knowing why it crashed.
This could lead to repeated crashed and system overload.

You'd need to configure at least number of restarts allowed in specified
time... if it's production system, it should have backupe, shouldn't it?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.

10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!

[Alexander Gurvitz]

 

I don't think it's wise to respawn named without knowing why it crashed.
This could lead to repeated crashed and system overload.

1. I have a system whose only reason to exist is running bind, once bind stops I don't mind the whole system overload, crash or go to hell.

2. When I've seen that my bind is down, the first thing I did is restarting it. I don't know why it crashed and probably never will, yet I don't see it as valid reason to never start bind again.

You'd need to configure at least number of restarts allowed in specified
time...

Agree. That's why there's a "restart limit 3 [times in] 10 [seconds] " in my upstart job.

if it's production system, it should have backupe, shouldn't it?

Yeah, I don't see how it related though.

Alex,

net-me.net

[Anand Buddhdev]

On 29/11/2012 11:25, Alexander Gurvitz wrote:

Hi Alexander,

> I'm trying to run a bind9 from an upstart job instead of an init.d script.
> I'm a bit confused if I should "expect fork" or "expect daemon". It seems
> to work with "expect fork", though somehow I don't feel convinced.

Actually, you don't need either. If you start BIND with the "-f" option,
it remains in the foreground, and this is the best way to run daemons
under upstart (and also OSX's launchd). See below.

> (Upstart must know how the daemon forks - if it forks once,
> "expect fork" should be specified, and if a daemon forks twice,
> it should be "expect daemon". Then upstart will wait for that forkings and
> will monitor the final PID).
>

> Thanks in advance,
> Alexander Gurvitz,
> net-me.net
>
> P.S My /etc/init/bind.conf:
>

> start on runlevel [2345]
> stop on runlevel [!2345]
>
> pre-start script
> # dirs under /var/run can go away on reboots.
> mkdir -p /var/run/named
> chmod 775 /var/run/named
> chown root:bind /var/run/named >/dev/null 2>&1 || true
> end script
>

> exec /usr/sbin/named -u bind

Replace this with "exec /usr/sbin/named -f -u bind"

> pre-stop exec rndc stop -p

>
> post-stop exec logger -p user.warning -t upstart-bind "bind stopped"
>

> expect fork

Remove this "expect fork".

> respawn
> respawn limit 3 10
> kill timeout 30
> console none

Regards,

Anand Buddhdev
RIPE NCC