supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Alexis <flexibeast@gmail.com>
To: supervision <supervision@list.skarnet.org>,
	skaware <skaware@list.skarnet.org>
Cc: "Hoël Bézier" <hoelbezier@riseup.net>
Subject: Re: s6-rc user services on Gentoo
Date: Wed, 03 Apr 2024 10:44:26 +1100	[thread overview]
Message-ID: <87bk6rnxd1.fsf@gmail.com> (raw)
In-Reply-To: <Zgvhe5mUxvJpX69a@sparta> (=?utf-8?Q?=22Ho=C3=ABl_B=C3=A9zier?= =?utf-8?Q?=22's?= message of "Tue, 2 Apr 2024 12:44:10 +0200")


Hi Hoël,

Thanks for your reply!

Hoël Bézier <hoelbezier@riseup.net> writes:

> I feel you. IRC without bouncer is not always great for getting 
> help
> on some topics. ^^’

:-) Yeah, most of the time that i'm on IRC - which is rarely 
nowadays, due to the aforementioned "lots on my plate" issue - 
it's usually to try to offer help to others, rather than asking 
for help myself, where having a working bouncer is much less of an 
issue.

> Are you planning on having your user services supervisor itself
> supervised? And if so, by OpenRC or another instance of 
> s6-svscan?
> Just asking out of curiosity.

i hadn't really thought much about that, as i've been focusing on 
simply trying to understand the basics and get them working.

My initial thinking is that i'd start by setting up the user 
services tree from .zlogin, i.e. the s6-svscan process itself 
would be unsupervised. Part of the reason for doing so is that, at 
this point, i primarily want to be using s6-rc to be able to 
manually restart user services in various situations (e.g. config 
changes), with service availability being secondary to that. But 
another part of the reason is that, in these contexts, i generally 
work best from the bottom-up, starting from what i consider to be 
the 'core' and then 'working outwards' from that.

(Yes, i know that's not always the most appropriate approach, 
particularly in contexts where security topics are inherently part 
of the 'core', and can't just be "bolted on" afterwards. i don't 
feel this is particularly the case here.)

i guess i'd probably want OpenRC supervising the user s6-svscan 
process, mainly because, at this point, i'd like to keep using 
OpenRC on my Gentoo system overall: since a lot of my volunteer 
tech work involves providing support to others and 
writing/maintaining documentation, it's useful to keep my own 
system fundamentally similar to what others are running.

> Your scandir and your service definitions are the same 
> directory,
> which they should not be.

> You currently have:
> * service_definitions="${xdg_data_home}/s6-rc/services"
> * compiled_services="${xdg_state_home}/s6-rc/compiled"
> * scandir="${xdg_data_home}/s6-rc/services"
> * livedir="${xdg_runtime_dir}/s6-rc"
>
> However service definitions can not be used as a scandir: if 
> your
> services are to be managed by s6-rc they should not be present 
> at
> start in your scandir but should be added there by s6-rc-init.
>
> That’s why s6-rc-init complains about files already existing: it 
> tries
> to create a symlink in the scandir pointing to the services it’s
> managing but it can’t because the service are already present in 
> the
> scandir.

Ah! Now i get it. Thank you. :-) i'm not sure how my reading of 
the s6-rc-init documentation led me to this; i'll need to review 
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, 
> or
> complained about directories containing no service (oneshots are 
> not
> supervised by s6-svscan, because there’s nothing to supervise in 
> them,
> so it doesn’t know about them).

*nod*

> What you should have is:
> * service_definitions="${xdg_data_home}/s6-rc/services"
> * compiled_services="${xdg_state_home}/s6-rc/compiled"
> * scandir="${xdg_runtime_dir}/services"
> * livedir="${xdg_runtime_dir}/s6-rc"
>
> Your scandir should be in your runtime dir because it does not 
> contain
> data but the current running configuration of your system. It 
> can be
> an empty directory when you start s6-svscan, there is nothing 
> wrong
> with that. s6-rc will populate it according to the compiled 
> 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 
> Alexis for the double send.)

No worries. :-)


Alexis.

  reply	other threads:[~2024-04-02 23:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02  4:42 Alexis
2024-04-02 10:44 ` Hoël Bézier
2024-04-02 23:44   ` Alexis [this message]
2024-04-02 20:57 ` Guillermo
2024-04-03  0:12   ` Alexis
2024-04-03 11:37   ` Laurent Bercot
2024-04-06 12:43     ` Guillermo
2024-04-06 13:57       ` Laurent Bercot
2024-04-06 15:57       ` Muhammad Mahendra Subrata
2024-04-06 18:31         ` Laurent Bercot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bk6rnxd1.fsf@gmail.com \
    --to=flexibeast@gmail.com \
    --cc=hoelbezier@riseup.net \
    --cc=skaware@list.skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).