Re: Upstart job for BIND9
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 21 || 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upstart job for BIND9
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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upstart job for BIND9
On Thu, Nov 29, 2012 at 7:25 PM, Matus UHLAR - fantomas uh...@fantomas.skwrote: 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! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Upstart job for BIND9
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 21 || 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upstart job for BIND9
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 21 || 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upstart job for BIND9
Hello Alexander, Alexander Gurvitz a...@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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upstart job for BIND9
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... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upstart job for BIND9
On Thu, 2012-11-29 at 13:35 +0100, Carsten Strotmann wrote: Hello Alexander, Alexander Gurvitz a...@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. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
