From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1858 Path: news.gmane.org!not-for-mail From: "rehan khan" Newsgroups: gmane.comp.sysutils.supervision.general Subject: RE: /service vs /var/service vs /etc/service Date: Tue, 22 Apr 2008 17:24:51 +0100 Message-ID: <50F2BE60A0EF6D478B1BCC633DEC28CC082D64@server.home.internal> References: <43362.24.8.235.144.1208550740.squirrel@www.xagasoft.com> <48091595.1040101@robinbowes.com> <20080418221145.GL1498@home.power> <4809311F.3060804@robinbowes.com> <20080419132517.6752.qmail@7bcdc3a3e39f79.315fe32.mid.smarden.org> <4809F52F.1020306@robinbowes.com> <20080419135414.12570.qmail@4bcbc2195532ad.315fe32.mid.smarden.org> <283B46AC657546A883A45437109FE51D@home.internal> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1208881688 407 80.91.229.12 (22 Apr 2008 16:28:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2008 16:28:08 +0000 (UTC) To: Original-X-From: supervision-return-2093-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Apr 22 18:28:37 2008 connect(): Connection refused Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1JoLLH-0002IQ-HN for gcsg-supervision@gmane.org; Tue, 22 Apr 2008 18:27:39 +0200 Original-Received: (qmail 12833 invoked by uid 76); 22 Apr 2008 16:27:19 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 12821 invoked from network); 22 Apr 2008 16:27:19 -0000 Original-X-Trace: 101495776/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/81.86.133.231 X-SBRS: None X-RemoteIP: 81.86.133.231 X-IP-MAIL-FROM: rehan.khan@dsl.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADquDUhRVoXn/2dsb2JhbACsfg X-IP-Direction: IN Content-class: urn:content-classes:message In-Reply-To: <283B46AC657546A883A45437109FE51D@home.internal> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: /service vs /var/service vs /etc/service thread-index: AciiJ+NVsR0BDlf4Rnyd9nv/hDVwGQCTbD4g Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1858 Archived-At: Hi all, A very interesting discussion. I came across similar issues. The standardised linux filesystem causes some issues in layout for runit services where more configurability would come in handy. Some points I would like to throw out for discussion are: 1) Although I have not extensively tested it I think SE Linux doesn't get so easily fooled by all this sym linking. An application constrained by SE Linux will be denied access to areas it is not allowed to access by policy. So runit sevices might need to have additional policy to support this. Having the service directories in /etc/init.d/service/NAME kind of works around this issue as the service directories inherit init's SE Linux policy after a relabel but this doesn't really fix all the potential problems. However this actually works out quite well as SysV init utilises scripts and runit utilises directories and so everything can fit into init.d or rc.d without causing too much confusion. Recently SE Linux has been adopted by more distros and this could become a more pressing issue (not just for Red Hat/Centos/Fedora where it is enabled by default). 2) 'Shared memory' (on fedora /dev/shm - a tmpfs filesystem) might be a good place to store the supervise directories as they are usually small in size. They would also get erased on a reboot which is not such a big issue as runit will re-create them. This would also alleviate a small amount of disk i/o (=3D=3Dthrashing) during start-up. Not a big issue = for servers I guess but more important for desktop/laptop systems where restarting is more common (at least until suspend/resume works out of the box for more machines). The log directories would of course have to point to a normal file system. This has the same issue as /var/run as it will definitely get cleaned out on a reboot so the run script will have to ensure that permissions are set correctly (which it should be doing anyway to be robust). So based on the above I would suggest a possible layout as follows: (configuration) - /etc/rc.d/SERVICE NAME or /etc/rc.d/service/SERVICE NAME for the service directories (or init.d instead of rc.d). (working files) - /dev/shm/supervised/SERVICENAME (logs) - /var/log/Service/SERVICE NAME or /var/log/SERVICE NAME A couple of other things that would be nice to have (but off topic): 1) To enable runit to mirror more closely sysv init scripts that start multiple processes. For example the nfs init script on Fedora starts three or four services which together provide nfs. To mirror this as a runit managed service one could use the main runsv to run a second runsv as a service which started the same services but in a grouping of their own. Right now if the secondary runsv is stopped (using sv stop) it orphans the services or sv proceses it was supervising instead of stopping them.=20 This could be implemented as a runsv switch which tells runsv to send a down command to all the services being managed and to wait until they have all exited (report back as down) before stopping the sv processes themselves and exiting itself. Using this, quite sophisticated service management can be implemented without having to have a bunch of additional related but separate service directories and the runit scheme would more closely resemble the init scripts in that distro. Another example would be the init script for vsftpd. This script dynamically creates processes for each configured ftp site. To mirror this I have a script which dynamically creates a service directory for each ftp site and then runs runsv to start them. Stopping runsv does not stop the vsftpd processes but orphans them. Being able to have runsv tear everything down (sensibly), after being sent a term and before exiting would make this just work. 2) It seems quite fashionable to connect things to the D-bus these days and I am wondering if runit can leverage some of d-bus' functionality to advertise services to the system or respond to service startup requests over d-bus or at least provide notification of start/stop events. Of course runit would have to start the d-bus service first :) I think I have mentioned this before and it was shot down as over-complicating things but it's still on my wish list. 3) A post-start script that sv runs if service X has been up for n number of seconds. This could be implemented as an option to sv (e.g sv -postart or sv -postart=3Dn), as a shell variable or if a poststart executable file exisis in the service directory then sv can just run it an n number of seconds after the service has started (or been up, like it does if the finish script exists). Although the number of seconds should be variable depending on the speed of the machine a sensible default could be used. As the original shell has been replaced by execing the service this would necessarily need to be run in it's own shell but sv would not have to supervise it, just run it assuming that the service has started successfully if it has been up for n number of seconds. This would be really useful. In fact a poststart script would negate the need for a d-bus interface as the d-bus stuff could just be done in the poststart (announces it is up) and finish scripts (announces it is down). Of course these things would be better demonstrated if I could produce some code but C is a mystery to me. If there is some interest I could probably do something in Python as a proof of concept to see if these suggestions might be useful in the real world. Cheers rehan -----Original Message----- From: Robin Bowes [mailto:robin-lists@robinbowes.com]=20 Sent: 19 April 2008 15:16 To: supervision@list.skarnet.org Subject: Re: /service vs /var/service vs /etc/service Gerrit Pape wrote: > On Sat, Apr 19, 2008 at 02:35:43PM +0100, Robin Bowes wrote: >> Gerrit Pape wrote: >>> The Debian runit package now switched to /etc/service, and I'm about to >>> change runit to use /service by default, just as daemontools does. >>> daemontools in Debian, just like runit in Debian, uses /etc/service, and >>> recommends to create a compatibility symlink /service -> /etc/service. >> Out of interest, where do you/Debian/others put the actual service =20 >> directories, i.e. containing the run file and log dir? I currently use =20 >> /etc/sv/servicename and symlink to /var/service/ >=20 > Me/Debian: /etc/sv/, and the ./supervise symlinks point to > /var/lib/supervise/[.log]. /var/run/ turned out to not be > appropriate, since it might be cleaned up on reboot, losing permission > changes possibly made to the directory and files in it. Thanks - that fits in with my gut feeling too (that /var/lib should be=20 used rather than /var/run). Where can I get the update-service script from? Would it be worth=20 distributing that with runit? R.