Re: how to wrap properly a Red Hat / CentOS service into a daemontools service ?
Romain Pelisse <[email protected]> Wed, 5 Jan 2011 15:01:25 +0100
| Newsgroups | gmane.comp.djb.syslog |
|---|---|
| Message-ID | <[email protected]> |
--0022152d602525ca22049919d22c Content-Type: text/plain; charset=UTF-8 Hi Brian, Thanks for your answer. I'm happy to know that I'm not the only one thinking about this. I'll like your approach, and especially like the idea of having the "status" option of the service working (however, this can also be confusing if somebody is led to believe that service xxx stop will work as suspected - probably need to map this to the daemontools equivalent). Anyhow, it sounds to me that you actually wrote your own init.d script rather than reusing the one provided by the distribution for instance, if I want to daemontoolize nginx I need to wrote myself an /etc/init.d/nginx scripts rather than use in my run script the one already provided by package. About that, I just wonder, did you try to salvage those scripts (as they are) - and maybe run into any issue preventing you to do so ? I did a quick tryout and it fails but I'm wondering if I maybe missing something important (such as "it simply can't work because of ...."). If there is no reason I couldn't reuse those script - simply by calling them inside my "run" script, I guess it would be a nice approach to smoothly integrate packaged apps into daemontools. > I've done some work doing this same thing. Here's my general > framework , but I'd certainly be curious to hear how others have > handled this: > > - generate a run script for each service that runs it in the foreground. > > - write a SysV init script that ends up under init.d > > - include the ckhconfig directives, so you can make use of 'service > foo status' and so forth. > > - _exclude_ your runlevel from said directives; you want daemontools > to initiate this service, not rc.init. > > The last step may not be important to you; I like letting things > start up in parallel, not serially. > > I went so far as to have my SysV init scripts make use of a central > set of bash functions that would block until the service in question > was 'stopped' and 'started'; that made use of lsof to see if a named > resource (network port, for example) was consumed by the process > managed by service directory. This is important to our management > framework, but it's up to you. > > As we were maintaining a Linux-based appliance, all software > installation was managed by RPMs via kickstart. As such, I created > RPMs named 'foo-daemontools' that tackled the work of: > > - dropping in the service directory for the foo service > - renaming CentOS's stock /etc/init.d/foo with my own > - managing the new service under certain conditions. > > and so forth. I don't know how you're managing your platform, so > you may not care about such steps... > > > > > -- > > Romain PELISSE, > > *"The trouble with having an open mind, of course, is that people will > > insist on coming along and trying to put things in it" -- Terry > Pratchett* > > http://belaran.eu/wordpress/belaran > > -- > Brian Reichert <[email protected]> > 55 Crystal Ave. #286 > Derry NH 03038-1725 USA BSD admin/developer at large > -- Romain PELISSE, *"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett* http://belaran.eu/wordpress/belaran --0022152d602525ca22049919d22c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian,<div><div class=3D"gmail_quote"><div><br></div><div>Thanks for you= r answer. I'm happy to know that I'm not the only one thinking abou= t this. I'll like your approach, and especially like the idea of having= the "status" option of the service working (however, this can al= so be confusing if somebody is led to believe that service xxx stop will wo= rk as suspected - probably need to map this to the daemontools equivalent).= </div> <div><br></div><div>Anyhow, it sounds to me that you actually wrote your ow= n init.d script rather than reusing the one provided by the distribution fo= r instance, if I want to daemontoolize nginx I need to wrote myself an /etc= /init.d/nginx scripts rather than use in my run script the one already prov= ided by package.=C2=A0</div> <div><br></div><div>About that, I just wonder, did you try to salvage those= scripts (as they are) - and maybe run into any issue preventing you to do = so ? I did a quick tryout and it fails but I'm wondering if I maybe mis= sing something important (such as "it simply can't work because of= ...."). If there is no reason I couldn't reuse those script - sim= ply by calling them inside my "run" script, I guess it would be a= nice approach to smoothly integrate packaged apps into daemontools.</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im"> </div>I've done some work doing this same thing. =C2=A0Here's my ge= neral<br> framework , but I'd certainly be curious to hear how others have<br> handled this:<br> <br> - generate a run script for each service that runs it in the foreground.<br= > <br> - write a SysV init script that ends up under init.d<br> <br> - include the ckhconfig directives, so you can make use of 'service<br> =C2=A0foo status' and so forth.<br> <br> - _exclude_ your runlevel from said directives; you want daemontools<br> =C2=A0to initiate this service, not rc.init.<br> <br> The last step may not be important to you; I like letting things<br> start up in parallel, not serially.<br> <br> I went so far as to have my SysV init scripts make use of a central<br> set of bash functions that would block until the service in question<br> was 'stopped' and 'started'; that made use of lsof to see i= f a named<br> resource (network port, for example) was consumed by the process<br> managed by service directory. =C2=A0This is important to our management<br> framework, but it's up to you.<br> <br> As we were maintaining a Linux-based appliance, all software<br> installation was managed by RPMs via kickstart. =C2=A0As such, I created<br= > RPMs named 'foo-daemontools' that tackled the work of:<br> <br> - dropping in the service directory for the foo service<br> - renaming CentOS's stock /etc/init.d/foo with my own<br> - managing the new service under certain conditions.<br> <br> and so forth. =C2=A0I don't know how you're managing your platform,= so<br> you may not care about such steps...<br> <div><div></div><div class=3D"h5"><br> ><br> > --<br> > Romain PELISSE,<br> > *"The trouble with having an open mind, of course, is that people= will<br> > insist on coming along and trying to put things in it" -- Terry P= ratchett*<br> > <a href=3D"http://belaran.eu/wordpress/belaran" target=3D"_blank">http= ://belaran.eu/wordpress/belaran</a><br> <br> </div></div><font color=3D"#888888">--<br> Brian Reichert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D"mailto:[email protected]">= [email protected]</a>><br> 55 Crystal Ave. #286<br> Derry NH 03038-1725 USA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 BSD admin/developer at large<br> </font></blockquote></div><br><br clear=3D"all"><br>-- <br>Romain PELISSE,<= br><i>"The trouble with having an open mind, of course, is that people= will insist on coming along and trying to put things in it" -- Terry = Pratchett</i><br> <a href=3D"http://belaran.eu/wordpress/belaran" target=3D"_blank">http://be= laran.eu/wordpress/belaran</a><br> </div> --0022152d602525ca22049919d22c--