Hi Hoël,
Thanks for your reply!
Hoël Bézier <hoelbezier_at_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.
Received on Wed Apr 03 2024 - 01:44:26 CEST