From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/752 Path: news.gmane.org!not-for-mail From: Alex Efros Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit directory organization Date: Tue, 5 Apr 2005 09:37:43 +0300 Organization: asdfGroup Inc., http://www.asdfGroup.com/ Message-ID: <20050405063743.GA4691@home.power> References: <000a01c53970$dd986680$6601a8c0@GHDESK> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1112682991 25615 80.91.229.2 (5 Apr 2005 06:36:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Apr 2005 06:36:31 +0000 (UTC) Original-X-From: supervision-return-988-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Apr 05 08:36:29 2005 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14] ident=qmailr) by ciao.gmane.org with smtp (Exim 4.43) id 1DIhfC-000115-5G for gcsg-supervision@gmane.org; Tue, 05 Apr 2005 08:35:50 +0200 Original-Received: (qmail 27270 invoked by uid 76); 5 Apr 2005 06:38:07 -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 27264 invoked from network); 5 Apr 2005 06:38:06 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <000a01c53970$dd986680$6601a8c0@GHDESK> User-Agent: Mutt/1.5.6i Xref: news.gmane.org gmane.comp.sysutils.supervision.general:752 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:752 Hi! On Mon, Apr 04, 2005 at 04:48:55PM -0700, Gregg Howe wrote: > confuses me. Perhaps someone could explain how they organize their > service directories, svdir directories and run scripts. Boot/shutdown scripts: /etc/runit/1 /etc/runit/2 /etc/runit/3 Directory with service's run scripts repository: /service/ Directory with current active services: /var/service/ At least it's looks like this for usage/administration: when I need to install new service I will add it's run script to /service/SOMENEWSRV/, when I need to activate that service on current runlevel I will just symlink it into /var/service/: ln -s /service/SOMENEWSRV /var/service/ OR ln -s /service/SOMENEWSRV /var/service/NEW second form I use to choose between alternative realizations of same service, for example: ln -s /service/agetty-tty1 /var/service/tty1 ln -s /service/mingetty-tty2 /var/service/tty2 ln -s /service/apache2 /var/service/web ln -s /service/oops /var/service/webproxy Real fs layout is a little different. /var/service/ isn't a real directory - it's lust symlink to /etc/runit/runsvdir/CURRENT_RUNLEVEL_NAME/ which is a real directory and contain all these symlinks to active services in /service/. I don't use different runlevels, but if you need easy way to switch between runlevels you can use this layout: /etc/runit/runsvdir/somerealrunlevel1/ /etc/runit/runsvdir/somerealrunlevel2/ /etc/runit/runsvdir/somerealrunlevel3/ /etc/runit/runsvdir/current -> somerealrunlevel2 /var/service -> /etc/runit/runsvdir/current This way you will be able to switch between runlevels by just changing /etc/runit/runsvdir/current symlink. Of course, with this scheme script /etc/runit/2 should start `runsvdir` with '/var/service/' as first param. I prefer this layout because: - all contiguration-related files under /etc, so there is no need to backup /service/ or /var/service/ in addition to /etc - /service/ is mostly like /usr/ from administration view - it contain static run-scripts (which installed from 'baselayout' package or some service packages) and there is no needs to update these run-scripts except in very rare cases... yeah, I know there some dynamic files will be created (locks, pipes, etc.) in this directory and this is why this directory called /service/ instead of /usr/service/ - it's not completely static like /usr/, it's special directory for services with own special behaviour which differ from /etc, /usr and /var - there is no need to know current runlevel name to update it because I will add/remove symlinks only in /var/service/ directory I don't sure this layout is FHS-compliant, but looks like djb's and djb-like software, packaging system and proposed fs-layout will never be included in global standards like FHS, no matter how good they are. :( -- WBR, Alex.