Paul Sopka schrob:
> I do not think that providing only this option this is a good idea,
> since names are unique and dependencies are declared in the dependent
> service.
"It simplifies dependencies" sounds like a good reason to go with the
tryexec approach.
Cheers,
Jan
signature.asc
Descr
Overrides? No, this would make things confusing and error-prone. The
behaviour
of a set of source definition directories should not be influenced by
whether or not
you're compiling it with another set.
Thanks for letting me know!
Regards,
Paul
OpenPGP_0x71C7C85A2EA30F62.asc
Description: O
I think there's a misunderstanding here, I'll try again:
What I proposed is putting the service definitions into /usr, never copy
or link them to /etc, never modify them (except by package updates), and
let s6 execute them directly from there.
If the local admin wants something other than the ser
The best would probably be for s6-rc-compile to allow for multiple
definitions of a service,
letting later definitions override earlier ones, e.g.
s6-rc-compile ${OUTPUT_DB} ${SOURCE_1} ${SOURCE_2}
where seatd-srv in ${SOURCE_2} overrides seatd-srv in ${SOURCE_1}.
Would this be realizable Laur
Paul Sopka schrob:
> > > ... then begs the question: what's the advantage of having the
> > > ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
> > > does this save the admin over creating their own my_seatd service and
> > > disabling the one you provide?
> > > (Honest questio
... then begs the question: what's the advantage of having the
${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
does this save the admin over creating their own my_seatd service and
disabling the one you provide?
(Honest question, I don't fully grok s6.)
It doesn’t save any
From Jan:
That's a more reasonable size than your first example. Although this ...
Allowing the sysadmin to completely override the service.
Unfortunately this also forces the sysadmin to override the service for
every so little change,
... then begs the question: what's the advantage of havi
Am Do, Sep 19, 2024 am 07:51:50 +0200 schrieb Jan Braun:
Allowing the sysadmin to completely override the service.
Unfortunately this also forces the sysadmin to override the service for
every so little change,
... then begs the question: what's the advantage of having the
${S6CONFIGDIR}/system
Paul Sopka schrob:
> I am not sure if I understand correctly, the files under
> /usr/share/s6-rc/{user,system}
> are to be there only as a reference, not to be edited.
> Are you trying to say that the non-edited files should be symlinked rather
> than copied?
I was indeed trying to say that.
But o
A skeleton is not config data, and should thus be in /usr/
Possibly /usr/.../examples/...
I agree, the reason i put it there ist that /etc/s6-linux-init/skel/
exists (at least on Gentoo Linux), thus for consistency.
- The package manager puts service source directories and an initial
set of bu
Paul Sopka schrob:
> - The sysadmin or the user can copy a skeleton from
> /etc/s6-rc/skel/{config,src} (which is populated by the package
> manager with configs and initial bundles) to ${HOME}/.config/s6-rc/,
> this folder shall be used for configuration and custom user services.
A skeleton is no
Hey everybody,
yes this project is still alive and making progress - but real life is
taking its time toll.
I want to spark another discussion to collect some arguments and
perspectives:
As of now I have had the following structure:
- The package manager puts service source directories for
Is there an equivalent chainloader ("envfile"-style) that can be plugged
into the instanced user service directories' command line?
Having the same configuration file be read by tools with different
behaviors (for instance, it appears the pam_env's quoting support is far
more limited than envf
Is there an equivalent chainloader ("envfile"-style) that can be plugged
into the instanced user service directories' command line?
Having the same configuration file be read by tools with different
behaviors (for instance, it appears the pam_env's quoting support is far
more limited than envfile'
That said, it might be of interest to you, that s6-setlock does not appear
here: https://skarnet.org/software/s6/index.html.
Whoops. And nobody noticed that in 13 years? Shame on all of you. :P
Fixed, thanks!
--
Laurent
There's already pam_env to set environment variables. And from
pam_env.conf it can expand @{HOME} and presumably ${USER}, which should
be all you need to accomodate desktop stuff that expects XDG_* and
Thank you, this looks great!
Since it can also source a plain key=value file, it can source t
Hey,
I don't want to pick a side in the turnstile-or-not fight, so I
found something you seemed to agree on, to disagree with:
Paul Sopka schrob:
> > [...] and unless you want to make users replace their shell with
> > something like `/etc/execline-startup` as described in
> > https://skarnet.org/
I am resending this unsigned, since the message is too large otherwise.
- `/run/turnstiled/sessions` exposes similar data as your proposal's
`/run/session` folder (including being able to query the session type).
Take a closer look at the prior art before writing it off.
Thank you for pointing
Yes - but since you're using s6 anyway, you also have s6-setlock,
which features more options than flock. ;)
I will happily use s6-setlock!
That said, it might be of interest to you, that s6-setlock does not
appear here: https://skarnet.org/software/s6/index.html.
I wish you a nice week!
Besides consistency, putting those below $HOME would also break in NFS
setups where $HOME is shared among several machines.
Good point. I will keep the user logs at /var/log/s6/user/${USER} for now.
Please don't. There's already 2 different standards for dotfiles (XDG
and ~/.nameofprogram), inve
Hey,
Paul Sopka schrob:
> [ user services have service dir in /run and logs in /var ]
> What do you think about that reasoning?
Agree.
Besides consistency, putting those below $HOME would also break in NFS
setups where $HOME is shared among several machines.
> I do not *want* to adhere to the XD
Em qui., 11 de jul. de 2024 às 11:55, Paul Sopka escreveu:
> I will try and summarize what we have now.
>
> I hope you are fine with this.
Sure. Long e-mails get tiring to read and reply to, for both of us.
> https://skarnet.org/lists/supervision/3139.html
Frankly, your priorities when designin
Good point. If I understood everything correctly, this can be easily solved by the
"flock" command, right?
Yes - but since you're using s6 anyway, you also have s6-setlock,
which features more options than flock. ;)
--
Laurent
These two last points, if you really decide to implement them like that in
the final version, may require some synchronization, e.g. via file locking.
It is not impossible (I mean, it is quite unlikely, but especially with
automated CI systems not impossible *at all*) for two SSH sessions to
come
On my setup, logs are stored under a dot-directory in my home directory,
which avoids needing any cooperation from root when setting up user
services (and the mentioned risk of overlap between user and system
services).
Since I have a system service setting up the user service tree, this is
a non
On Thu, Jul 11, 2024 at 04:53:51PM +0200, Paul Sopka wrote:
> Since I was not 100% convinced by Turnstile, I made an attempt on a very
> simple alternative way to handle user session tracking.
>
> The (currently very crude) script only runs once on each login and logout
> and does the following:
>
On my setup, logs are stored under a dot-directory in my home directory,
which avoids needing any cooperation from root when setting up user
services (and the mentioned risk of overlap between user and system
services).
Due to /var == ~/.local/state according to the XDG spec (which, from your
othe
Should every s6-log daemon have it's own config file or shall they all share
one?
What kind of stuff are you putting in the config file? Is it just a
template for a logging script?
Is there any general issue with the global env's from s6-linux-init's env
directory, which makes sourcing the
I have another basic decision to make, on which I am interested to hear
everybody's opinion.
Should every s6-log daemon have it's own config file or shall they all
share one?
My initial instinct on this was to put the global logging settings into
the env directory of s6-linux-init to have al
Thanks for the extensive answer.
Since I feel like we are more and more fighting about each others
wording and the answers consisting of quotations of each other get
longer and longer, I will try and summarize what we have now.
I hope you are fine with this.
My approach(see here: https://sk
Since I was not 100% convinced by Turnstile, I made an attempt on a very
simple alternative way to handle user session tracking.
The (currently very crude) script only runs once on each login and
logout and does the following:
On login:
- Possibly create a /run/session/${USER} directory.
-
Em seg., 8 de jul. de 2024 às 09:55, Paul Sopka escreveu:
> You're making more work for yourself and the people who'd help you
> maintain the service set, and making an s6 policy with more
> assumptions.
>
> I disagree. If the most important work is delegated to the service
scripts, once it works,
Quick question (that you may have already thought about, apologies in
advance): what happens if one wants to start a new daemon that has
the same name as an already existing system user account?
Also, what happens if a new system user account is created with
the same name as an already configured
Peter Pentchev schrob:
> On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> > System supervision tree logs to to /var/log/${daemon}
> >
> > User supervision tree logs got to /var/log/${USER}/${daemon}
>
> Quick question (that you may have already thought about, apologies in
> advance):
On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> The last "thread" I open for this night. I promise.
>
> I currently have set up logging in the following way:
>
> System supervision tree logs to to /var/log/${daemon}
>
> User supervision tree logs got to /var/log/${USER}/${daemon}
Not sure what you mean by "instantiated services". But see below.
See here: https://skarnet.org/software/s6/instances.html.
Sorry for my tone, I realize I was grumpy, possibly offensively so. You
took it well, thanks. 🙂
No worries, in my opinion the focus should be on being more resilient
a
You're making more work for yourself and the people who'd help you
maintain the service set, and making an s6 policy with more
assumptions.
I disagree. If the most important work is delegated to the service
scripts, once it works, it works. Forever. Easy to adapt and replace by
sysadmins/users
Paul Sopka schrob:
> An alternative would be two main bundles per user service tree, that itself
> always starts on boot:
>
> One to start at boot time.
> Another one to start on first login and stop on last login.
> This seems the most elegant and efficient. Am I overlooking anything?
I am not t
Replacing crond with snooze, for example.
And personally, I want my ssh-agent to stay alive when I log out, so
that the key is still unlocked if/when I immediately log in again.
You have convinced me, I will see whether it is feasible to have a
*third* user-service tree. I fear I just have to b
Paul Sopka schrob:
> My claim was more about a practical, applied scenario. In the terms of: If a
> user is not logged in, he simply cannot control his services. So why shall
> he have an entire user supervision tree of which the sole purpose is to
> allow the user to control the services running w
Em dom., 7 de jul. de 2024 às 06:06, Paul Sopka escreveu:
> Instead, I want to delegate as few functionality to them as possible. Why
> should I e.g. delegate the creation a directory to a binary, configured
> through its own config file, if it would just be one line in a script that
> loads t
What I do is little different: my login shell is
/etc/execline-startup, which after setting up a few things, execs into
~/.execline-loginshell, which among other things execs into s6-envdir
reading the same env dir as my supervision tree, and finally executes
into my actual shell.
I’ll attach
foreground install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} ""
foreground install -d -o ${USER} -g ${USER} /var/log/${USER} ""
foreground install -d -o ${USER} -g ${USER}
${XDG_RUNTIME_DIR}/service ""
foreground { install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} }
foregrou
Hi,
Am Sa, Jul 06, 2024 am 03:09:26 +0200 schrieb Paul Sopka:
This brings me to the final problem which the alternative mentioned
above solves already: The user services manage a couple of things,
namely the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be
propagated to the users log
I don't think avoiding Turnstile (and similar projects) in favor of s6
services is reasonable, given the concerns you've raised in the first
block ofhttps://skarnet.org/lists/supervision/3122.html (especially
"I'd like for the user supervision tree to only start on-demand").
I do not want to av
I don't think avoiding Turnstile (and similar projects) in favor of s6
services is reasonable, given the concerns you've raised in the first
block of https://skarnet.org/lists/supervision/3122.html (especially
"I'd like for the user supervision tree to only start on-demand").
Turnstile's interface
Any environment variable you want to make available for a whole
supervision tree should be added via a "-e var=value" option to your
s6-linux-init-maker invocation.
Thanks, will do!
For user supervision trees, I suppose you're not using s6-l-i-m, so
the best place would be to put the variab
No, because the point is to allow users to have their own services,
and you definitely don't want them to have access to the root
supervision tree. So you basically have to have a separate subtree
for each user (a privilege-dropped s6-svscan), and there are a few more
policy questions to answer,
Wouldn't anything this does be solved by just dropping privileges of the
corresponding daemons in their startup scripts?
No, because the point is to allow users to have their own services,
and you definitely don't want them to have access to the root
supervision tree. So you basically have to
Concerning the system tree loggers, my first idea is to set an environment
variable somewhere in the scripts s6-linux-init provides.
Is this even possible?
What would be the best place to do this?
Any environment variable you want to make available for a whole
supervision tree should be a
The last "thread" I open for this night. I promise.
I currently have set up logging in the following way:
System supervision tree logs to to /var/log/${daemon}
User supervision tree logs got to /var/log/${USER}/${daemon}
Currently, the logging dir is hardcoded in all s6-log daemons. I want to
To keep all the stuff a bit organized, I will open another "thread" for
this.
I have read through
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
and to me the standards seem sensible. Most of it is the default of most
if not all modern desktop programs anyway.
Thanks for your input!
As Mobin said, Turnstile from Chimera Linux answers this problem, and
also manages the XDG_RUNTIME_DIR folder.
Since it actually has hooks to coordinate with the supervisor (unlike
elogind, where the systemd-specific code for that in logind is just
stubbed out), it makes
Hey, thank you for your detailed answer!
A. a permanent supervision tree, belonging to a normal user, that runs
services as the user, independent from whether the user is logged in.
Wouldn't anything this does be solved by just dropping privileges of the
corresponding daemons in their startup
I think "turnstile" is a suitable option for this purpose. It's
designed in three parts: a PAM module for detecting logins, a Daemon
and some service supervisor loader scripts (backends). Currently it
does support Dinit and Runit as backends but there should not be any
problem around writing a
1) A service monitoring logged in users, starting the user supervision tree on
the first login of a user and stopping it once the user logs out from the last
shell/display manager
Ah, user services. They're a complicated matter, and their exact
definition varies depending on the distro. They'
On ۱۴۰۳/۴/۱۵ ۱۷:۳۹, Paul Sopka wrote:
Hey everybody
I am currently working on implementing boot scripts, system services,
user services and general policy for Gentoo with s6/s6-rc.
I will soon (once I consider it acceptable) publish a github repo of my
current state, so others can criticize,
Hey everybody
I am currently working on implementing boot scripts, system services,
user services and general policy for Gentoo with s6/s6-rc.
I will soon (once I consider it acceptable) publish a github repo of my
current state, so others can criticize, improve and suggest components.
The p
58 matches
Mail list logo
