From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2400 Path: news.gmane.org!.POSTED!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Noclobber supervisor/init installation Date: Sun, 28 Oct 2018 15:33:45 -0300 Message-ID: References: <20181027151157.03f14173@mydesk.domain.cxm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540751511 20737 195.159.176.226 (28 Oct 2018 18:31:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Oct 2018 18:31:51 +0000 (UTC) Cc: joelz@pobox.com To: Supervision Original-X-From: supervision-return-1991-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Oct 28 19:31:47 2018 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gGpql-0005KM-Id for gcsg-supervision@m.gmane.org; Sun, 28 Oct 2018 19:31:47 +0100 Original-Received: (qmail 32354 invoked by uid 89); 28 Oct 2018 18:34:22 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32347 invoked from network); 28 Oct 2018 18:34:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=q6aHs/kTPftQKtymdWWTnCYzSuaLoKcawbY/vJWDDXY=; b=rUrWcoTRzXiDMMAwdyZ8ePnROpoxIVnzoYdMFgeZF3kwb0cOLxHhpZ7rlSmXH9mcMj FghCpwj59sIIQeRSFuAiepi0lUlhdSyttGAzXhcn7JE4CcLUFrhvs5Iug7sme8BJ8saY HMJVDQdGFZhQOG+lRW5xOtXi6vTrxofuWZIURWXL+v/6zm9H3QOAWXDaRKCCQz9wX+kq QrNagGToJlHuBZB933uNGs2Czk126smsmbz9mdSgoGnK0VWtO5AhMYlmW91E/8YoX7Za MlcVVPkxwjgTOBkDpY+U7kdvXoki8pZETrL/aJY16kLWIu4UR/+mt71Rx89Haste/cZM rxoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=q6aHs/kTPftQKtymdWWTnCYzSuaLoKcawbY/vJWDDXY=; b=C8bV7zLxRA8OLjtuEftmY9lP/WLchQ5Cr/XC6bGNbgsYnYtRFnZkHmrnbQDERkwieU C6figqlrAvIn1/nq4fIZ0C4PB5jkWG5QG0EHmPNAsmkfq8sQLba6ZVbDT1lwtf68mt3r 5rkEDpEWBzErfW+pXIMuUfOWxHcHRtIMVBKnV5KKJFFcD8zk+JonBRm/RwDWS+7qdqnj gESS+Yfot957cC+etMTllaGyu8o9SwqzdR4+fggQq4yC8enaW8CNCJzkDaLGCdugVPwU aaFyv9cJodNlWHbNsW2PXC0P0fMXkN/DnI0q3x6rTd4Upw30Zdusu2if8siZfcFnpY5Y warA== X-Gm-Message-State: AGRZ1gJvxjQUxBbkRkMu+E/JsATDBSRdGG8Y5EGJ6vsL6wMxq00g4No4 8FS+MC0Qh9VEicdSsISSjcB8NfY7/+8P3hPhRKTNiA== X-Google-Smtp-Source: AJdET5ed/cZ3SF22FEMb4Sk82VEoRZBLnZlRlUKSHpgyC1BF8jhpdnschb8mGWwKWmAYWmmgyD1q+/p6mtcG6f68s6Y= X-Received: by 2002:a6b:3954:: with SMTP id g81-v6mr6253029ioa.225.1540751634181; Sun, 28 Oct 2018 11:33:54 -0700 (PDT) In-Reply-To: <20181027151157.03f14173@mydesk.domain.cxm> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2400 Archived-At: Hello, El s=C3=A1b., 27 oct. 2018 a las 16:12, Steve Litt escribi=C3=B3: > > So I've created the following terminology: > > du: Daemons used. Refers to the symlink directory or its > subdirectories. /service in the original daemontools is an example > of a du directory. /etc/sv in both Void Linux and Debian and Devuan > is an example. In Devuan I'd make this directory /etc/du/runit. > There could later be an /etc/du/s6 or /etc/du/daemontools. This one already has a name: scan directory (the pathname argument runsvdir is invoked with). However, I believe that this is /run/runit/runsvdir/current on Void, and /etc/service on Debian, not /etc/sv. In the first case, that's a symbolic link to /etc/runit/runsvdir/current so that one can use runsvchdir(8): * http://www.smarden.org/runit/runlevels.html In the second case, that's a symbolic link to /etc/runit/runsvdir/default apparently? If so, your proposed location would differ from that of Debian stretch's and buster's runit package, and therefore currently Devuan ASCII's and Beowulf's, right? Wouldn't Devuan have to fork the package to change the convention then? * https://packages.debian.org/stretch/amd64/runit/filelist * https://packages.debian.org/buster/amd64/runit/filelist > da: Daemons available. Refers to the directory housing the real-file > directories that are symlinked in the du directory. Material in the > da galaxie is site-modifiable to accommodate site specific needs. > In Devuan I'd make this directory /etc/da/runit. There could later > be an /etc/da/s6 or /etc/da/daemontools. > > dp: Daemons packaged. Refers to a directory housing unmodified > material straight from the runit_daemons package. The dp directory > shall consist of a directory holding daemon directories for every > daemon in the collection. The daemon directories shall not contain > any supervise file, directory or symlink, nor any log files or > directories meant to hold log files, nor any other stateful > things. The intent of the dp directory is that its material is > modified ONLY by later packages, never on-site. It's therefore > entirely read-only. In Devuan I'd make this directory /etc/dp/runit. > There could later be an /etc/dp/s6 or /etc/dp/daemontools. I usually call these 'service directory repositories', and I believe on both Void and Debian that is a single directory, /etc/sv, managed by the package manager, just like /etc/init.d. Again, wouln't changing the convention set up by Debian packages require a fork? * https://packages.debian.org/stretch/all/getty-run/filelist * https://packages.debian.org/buster/all/getty-run/filelist > runit_tool -i daemonname sees whether the dp version of the daemon dir > matches the da version, and if so, does nothing. If different or da > version is missing, it first backs up the existing dp version then > overwrites it. If the now backed-up dp version matches the da version, > the da version is assumed not to be custom, and the new dp version > overwrites the da version. If the backed-up dp and the da differ, it > assumes the da version is customized, and via backups and warnings, > walks the user through his/her choices. > > runit_tool -e daemonname creates a symlink of the da in du. If nothing > to symlink to, issues a warning. > > runit_tool -d packagename removes that symlink. If no symlink, > issues a warning. > > runit_tool -u daemonname issues a warning and refuses to act if > there's currently a du->da symlink. If the da version of the daemon > doesn't match the dp version, issues a warning about it being > customized, and makes the user strenuously opt in to deleting the > daemon directory from da. Does not affect dp at all. Doesn't this overlap functionality (in a contradictory way) with update-service(8) (a Debian addition to runit)? * https://salsa.debian.org/runit-team/runit/raw/master/debian/contrib/updat= e-service G.