>Thanks Peter, this was actually helpful and enchanced my mental model.
>I think I get get away for now with a user's tree rooted in the system
>tree. My graphics environment (sway) can start necessary services
>when it is started.
Yeah, it's a recurring discussion on the IRC channels, and my answer
is always that "user services" as systemd does them aren't a well-
defined concept - "logging in" doesn't always have a clear meaning:
do sshd logins count? Or only seat sessions? What happens when the same
user logs in via 2 different seats and 1 sshd, then logs out of one
seat? then of the second seat? Should the services be stopped, and if
so, when?
systemd has to make choices and makes things work, more or less, in the
common case of one user at one seat - but that's a very unsatisfying
answer from a developer's point of view.
s6 users are also more likely to log in remotely more often than
systemd users, so maybe systemd's choices aren't the best ones for s6.
"User services" are a can of worms, and since I'm always very reluctant
to enforce policy on users or make choices that will not work in all
cases, it's not one that I'm willing to open beyond what's provided by
s6-usertree-maker.
I'm happy that you can work with a permanent user tree - that is a
well-defined concept that can be implemented and wholeheartedly
supported with s6.
>By testing I meant checking if the directory has an active process
>watching it. I believe there is a function in skalibs fd_lock [1]
>that svscan uses to check if another svscan runs there. I think it is
>just a matter of exposing that function as standalone executable.
There are no executables to test whether s6-svscan or s6-rc are
running on a given directory, because these are not dynamic properties.
By policy, decided by you or your distro, you should *know*, at all
times, whether a given directory is a scandir with an s6-svscan running
on it - or whether a given directory is a livedir with s6-rc running
on it.
If you think a given directory should have an s6-svscan running on it,
then you're right; ensure that s6-svscan is started at boot time, and
write your scripts assuming that it's there. If something fails because
it's not there, that's a bug or a system problem, and needs to be fixed,
not accommodated by your scripts.
--
Laurent
Received on Tue Oct 18 2022 - 02:58:08 CEST