From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from alyss.skarnet.org (alyss.skarnet.org [95.142.172.232]) by inbox.vuxu.org (Postfix) with SMTP id C270A2221B for ; Wed, 3 Apr 2024 01:44:36 +0200 (CEST) Received: (qmail 60444 invoked by uid 89); 2 Apr 2024 23:45:00 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 60430 invoked from network); 2 Apr 2024 23:44:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712101471; x=1712706271; darn=list.skarnet.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=e/YqI7B3pbnPZvE0VpuTpbwU8SPBJBBa/UaBUhKMLI8=; b=fgazhpxsEmSAwbO+TJMtE0ppyB2D5TZ0YhdyJ+fs7Ln0/FmNk3rdIjAK5KEalnaBjW P8Q7qrh0Q5QoIzJ/P/13NCrXk/ElPzyvDfycv3jzOQZg+Li5Z8LCD+746iz/Mnlxbfjp Kv3z3PZoie1g1qUcPQj6XJ9r4aIUt2M2/uFNaLDIC3onoVYFL/cxxakpgelrsIx7idt1 0cawkxCtkmfIa2x/jpEbRiqxtLD5lGqzBDTryTyzasTNpkhEETvkhnuTLjsvbhf5zCji HsHRsAYJ0QcPZN7WE0oQsvHa3XCL8lF8XfLCunJaPrvK9P8YjNqPFfne7/ZD7u0Zp4v4 1iVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712101471; x=1712706271; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=e/YqI7B3pbnPZvE0VpuTpbwU8SPBJBBa/UaBUhKMLI8=; b=bAxr+wjRqmQlwzxGTy0rKC7Fy41Pje7mMm+PjHk/UBazL1T1ZUQqrkVGvh1zj0IfeV tCpcL7N6G+1rmK4hj/hzQe7T2sWfyrQfrI/k7bKVptUTM24zXGcrrgbpQCEj/azFtDrS T7v29FIr5qNcNt3cYCuwba58OVpA+mKzntbtcVhDQ/iErKeBBJhM9xg18IeCTUvuhaPw 6Rn5vZYdGCyIKS6vZrCA3D4F1HCOT0Lr9/h2ANwE/ysmcLnnXy2FKkCwCYNN4o2Fp7VD RkZK2afH1LP3KE/9isSM1xjCxy898mFtZfeSGBYEwxXUR+vZ19pHtspKWi1cTli6Gl1t Z7KA== X-Forwarded-Encrypted: i=1; AJvYcCXSmHMd/SclZY5Ha8wTbKl/9pIlwFrG747yUa42BRDVfxCxnt9znFrPGTAyoRzBdwtU3NzfPcuGAqy5SdHxW0XAu8XW99frUYU= X-Gm-Message-State: AOJu0YwI/rknX7kY1kqJ90WxBXZJUYRMS3HRWc7+fjTVDFIGa8QJ2TS1 xL0gwODuvZuLbluSuOqHaNAURHJ1TkIVCqYb+IGuMabAM1vhZXYtLnDsMl8wunc= X-Google-Smtp-Source: AGHT+IGrgL6G6XU+yXHmIsBPIc2qQ/PVgdFqfA5BxIc3v6QSNp3VcRujPwvf2BYHQotCFhhAW3z9qQ== X-Received: by 2002:a05:6a00:1d1d:b0:6ea:89e5:99a3 with SMTP id a29-20020a056a001d1d00b006ea89e599a3mr1307477pfx.8.1712101470819; Tue, 02 Apr 2024 16:44:30 -0700 (PDT) From: Alexis To: supervision , skaware Cc: =?utf-8?B?SG/Dq2wgQsOpemllcg==?= Subject: Re: s6-rc user services on Gentoo In-Reply-To: (=?utf-8?Q?=22Ho=C3=ABl_B=C3=A9zier?= =?utf-8?Q?=22's?= message of "Tue, 2 Apr 2024 12:44:10 +0200") References: <87jzlgnzoh.fsf@gmail.com> User-Agent: mu4e 1.12.2; emacs 29.3 Date: Wed, 03 Apr 2024 10:44:26 +1100 Message-ID: <87bk6rnxd1.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ho=C3=ABl, Thanks for your reply! Ho=C3=ABl B=C3=A9zier writes: > I feel you. IRC without bouncer is not always great for getting=20 > help > on some topics. ^^=E2=80=99 :-) Yeah, most of the time that i'm on IRC - which is rarely=20 nowadays, due to the aforementioned "lots on my plate" issue -=20 it's usually to try to offer help to others, rather than asking=20 for help myself, where having a working bouncer is much less of an=20 issue. > Are you planning on having your user services supervisor itself > supervised? And if so, by OpenRC or another instance of=20 > s6-svscan? > Just asking out of curiosity. i hadn't really thought much about that, as i've been focusing on=20 simply trying to understand the basics and get them working. My initial thinking is that i'd start by setting up the user=20 services tree from .zlogin, i.e. the s6-svscan process itself=20 would be unsupervised. Part of the reason for doing so is that, at=20 this point, i primarily want to be using s6-rc to be able to=20 manually restart user services in various situations (e.g. config=20 changes), with service availability being secondary to that. But=20 another part of the reason is that, in these contexts, i generally=20 work best from the bottom-up, starting from what i consider to be=20 the 'core' and then 'working outwards' from that. (Yes, i know that's not always the most appropriate approach,=20 particularly in contexts where security topics are inherently part=20 of the 'core', and can't just be "bolted on" afterwards. i don't=20 feel this is particularly the case here.) i guess i'd probably want OpenRC supervising the user s6-svscan=20 process, mainly because, at this point, i'd like to keep using=20 OpenRC on my Gentoo system overall: since a lot of my volunteer=20 tech work involves providing support to others and=20 writing/maintaining documentation, it's useful to keep my own=20 system fundamentally similar to what others are running. > Your scandir and your service definitions are the same=20 > directory, > which they should not be. > You currently have: > * service_definitions=3D"${xdg_data_home}/s6-rc/services" > * compiled_services=3D"${xdg_state_home}/s6-rc/compiled" > * scandir=3D"${xdg_data_home}/s6-rc/services" > * livedir=3D"${xdg_runtime_dir}/s6-rc" > > However service definitions can not be used as a scandir: if=20 > your > services are to be managed by s6-rc they should not be present=20 > at > start in your scandir but should be added there by s6-rc-init. > > That=E2=80=99s why s6-rc-init complains about files already existing: it= =20 > tries > to create a symlink in the scandir pointing to the services it=E2=80=99s > managing but it can=E2=80=99t because the service are already present in= =20 > the > scandir. Ah! Now i get it. Thank you. :-) i'm not sure how my reading of=20 the s6-rc-init documentation led me to this; i'll need to review=20 it, so that i can perhaps offer some changes/additions. :-) > Moreover, had you had any oneshots in your service definition > directory, I think s6-svscan would have simply failed to start,=20 > or > complained about directories containing no service (oneshots are=20 > not > supervised by s6-svscan, because there=E2=80=99s nothing to supervise in= =20 > them, > so it doesn=E2=80=99t know about them). *nod* > What you should have is: > * service_definitions=3D"${xdg_data_home}/s6-rc/services" > * compiled_services=3D"${xdg_state_home}/s6-rc/compiled" > * scandir=3D"${xdg_runtime_dir}/services" > * livedir=3D"${xdg_runtime_dir}/s6-rc" > > Your scandir should be in your runtime dir because it does not=20 > contain > data but the current running configuration of your system. It=20 > can be > an empty directory when you start s6-svscan, there is nothing=20 > wrong > with that. s6-rc will populate it according to the compiled=20 > services > you feed him. *nod* Thanks for all this, it's been very helpful! > You can see my own outdated s6-rc system service definitions at: > * https://forge.dotslashplay.it/s6-rc/system-services > and my (also outdated) s6-rc user tree service definitions at: > * https://forge.dotslashplay.it/s6-rc/personal-services i'll definitely take a look! > (resending this to the list as I only replied to Alexis, sorry=20 > Alexis for the double send.) No worries. :-) Alexis.