Coming back after doing some tests. I like its general behaviour,
especially with the `s6` command defaulting to system, not user.
Now the problems that I encountered:
When some `XDG_*_HOME` variable aren't set, I get this:
```
[user_at_PC-1 ~]$ s6 -u version export
version=0.1.0.0
scandir=/run/user/1000/service
livedir=/run/user/1000/s6-rc
repodir=${XDG_STATE_HOME}/s6/repo
bootdb=${XDG_STATE_HOME}/s6/rc/compiled
stmpdir=/run/user/1000/s6-frontend
storelist=/etc/s6/user/sv/:/etc/s6/user/adminsv:${XDG_CONFIG_HOME}/s6/sv
[user_at_PC-1 ~]$ s6 -u set status
s6-rc-set-status: fatal: unable to lock ${XDG_STATE_HOME}/s6/repo:
No such file or directory
```
1. When `XDG_*_HOME` variables aren't set, paths aren't resolved.
2. The error doesn't tell me what's wrong.
For problem 1, I propose 2 options, personally prefer option a:
a) Add another interpretable config variable for `$HOME`, that can be
set in the config instead of XDG variable usage.
Resolve `$HOME` like this:
Get it from env, fallback to `getpwuid(getuid())` when it isn't set.
b) When an `XDG_*_HOME` variable isn't set, fallback to default XDG
paths relative to the home directory. Example:
`XDG_CONFIG_HOME` isn't set -> resolve the home directory,
and construct it as `/home/user/.config`.
For problem 2, I propose showing a simple error when **any**
of the paths in the config is unresolvable.
I would like to submit the code myself, if/when we agree on any solution.
If I'll propose the exact patch, can I be credited as a commit author?
On Fri, Sep 11, 2026 at 8:18 AM Laurent Bercot
<ska-supervision_at_skarnet.org> wrote:
>
> >I didn't use LLM for translation. In this case I used it for learning
> >new things(C language, login/session/service management in linux),
> >inspecting new codebases(s6 repos, systemd, dinit, elogind, turnstile,
> >userspawn, etc.),
>
> You don't have to believe me, but you can learn just as well by going
> to
> Codeberg (or GitHub if you have to) and browsing the code of the
> projects
> you're interested in. And if you have questions or want to discuss
> things,
> going to any project community and talking to the humans there. 🙂
>
> We have an #s6 channel on the oftc.net IRC, that's where most of the
> informal discussions happen. Join us!
>
>
> >I asked LLM to make my initial text more readable, with examples, and
> >with proper
> >formatting for the mailing list. I also don't like writing long texts
> >to other people,
> >having to tickle human brains' erogenous zones(some people call it
> >"making the text sound strong" or "sound polite/professional").
> >LLMs are better than me in that regard. For that reason I use LLM with emails.
>
> I think you'll find most people, at least in the FOSS community and
> *definitely* on this list, prefer to read your short, not-tickling,
> not-professional e-mail, rather than the polite version. Give your
> thoughts raw; that may require some work of interpretation, but we
> _also_
> have to do some work of interpretation with LLM output because it adds
> a lot of uncertainty: what did you really want to say and what was
> flavor
> text added by the LLM? That's additional work that I absolutely don't
> want
> to do.
>
> As evidenced by this e-mail, your prose is fine. You're making yourself
> understood. That's enough.
>
>
> >I still hope I can contribute to your codebase, despite being new with C.
>
> Rather than contributing to the codebase, I'd like you to contribute to
> the _design discussion_ (which you're doing, so thanks!) because you're
> experienced with user services and I'm not. Once we know exactly what
> we want to do, code is generally easy.
>
>
> >I think UID instead of env only, makes it better, but personally,
> >I disagree with `--system` flag, since it's kinda unobvious for a new
> >user, and i think explicitness is better here. But you know this system better,
> >so I won't argue. It allows to use distro-packaged per-user services anyway.
>
> There has been some discussion on the #s6 channel, and voices are not
> unanimous.
> An objective fact is that both OpenRC and systemd always address
> system services by default, and need an explicit --user to address user
> services, even when invoked with uid != 0.
> My question was, is it more natural to do it this way, or does it make
> more sense for normal users to access their own user service database by
> default (since they cannot modify system services anyway).
> Some people say that users access the system services more anyway,
> almost never touch user services, and want consistent behaviour no
> matter
> their uid, so the OpenRC way of doing it is better.
> Others say that my initial inclination is right and "s6 foobar" should
> mean the user service by default unless invoked as root.
>
> In the absence of a consensus, and of a significant sample of UX
> returns
> on calling the service manager as a non-root user, I have changed my
> mind
> and now think keeping things simple and consistent, as systemd and
> OpenRC
> do, is the best; the default can be changed later if UX returns say it
> needs to be.
>
>
> >1. Setting s6-user.conf path at compile time, like it is done with s6.conf
> >2. Reading the interpretable paths at runtime.
> >
> >And you seem to have added them in your last commit. Thank you for
> >that, I'll try it out.
>
> It's untested, so if you have any issues with the changes, please
> report
> them!
>
> --
> Laurent
>
Received on Wed Sep 23 2026 - 18:37:08 CEST