Re: s6-rc as user service manager
On 2022-10-18 00:58, Laurent Bercot wrote: > > 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. > These tests made sense in the situation of user's services as systemd does it. (Like answering a question whether another login shell has already spawned svscan) It is indeed not necessary with static user tree. Ihor
Re: s6-rc as user service manager
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
Re: s6-rc as user service manager
On 2022-10-17 23:42, Peter Shkenev wrote: > ... > 1) User services are services running as a given user and started at a > boot time > This option is a trivial one with s6. > > 2) User services are services defined by users and running supervised > when the user wants it. > You can implement this with s6-usertree-maker [1], which would provide > you with a supervision tree rooted in a system one which can be managed > by user. User will have its own scandir and they can use all commands > provided by s6/s6-rc on their scandir. 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. > > - Minor: a test utility for svscan dir would be nice > > - Minor: a test utility for live dir would be nice > > If you use s6-rc, those are the same directories, filled by s6-rc-init > and changed by s6-rc-update. So the test would actually test those > utilities, I guess. 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. [1] https://github.com/skarnet/skalibs/blob/master/src/libstddjb/fd_lock.c Ihor
Re: s6-rc as user service manager
Hello, On Mon Oct 17, 2022 at 8:50 PM MSK, Ihor Antonov wrote: > Kicking off another thread because it is slightly different from UX > related questions. > > I am trying to get s6-rc set up as a user service manager (similar how > systemd allows user's to manage their own services with systemctl --user > start bla). > This is useful for example for starting user's dbus, pipewire, > xdg-desktop-portal services, and other stuff that is strictly user > related. > > This usecase is geared towards a desktop/laptop. (There were numerous rants of user services by Laurent Bercot and Colin Booth on IRC, and I'm going to use those rants as a source). Firstly, let's try to define "user services" without "bla". There are three very different options: 1) User services are services running as a given user and started at a boot time This option is a trivial one with s6. 2) User services are services defined by users and running supervised when the user wants it. You can implement this with s6-usertree-maker [1], which would provide you with a supervision tree rooted in a system one which can be managed by user. User will have its own scandir and they can use all commands provided by s6/s6-rc on their scandir. 3) User services are services that are started when user logs in. I guess this is what you had in mind when you was typing your letter. This is the hardest one and badly defined one. There are a lot of questions: - What does "user logs in" mean? Do we want services to be started when user logs in on the console or at seat? Sshd? Serial line? - When do we stop services? "When the user logs out"? And if the user has both an X session and a shell in a console? We need to wait for the last connection to drop? How would we get this information? One needs some time to shut down the supervision tree. One can remember how did systemd killed all user processes on the logout. - Moreover, some services (pipewire, for example) are supposed to be run in certain cases, e.g. a graphical session. - There may be a lot of questions I don't know about. > - Minor: a test utility for svscan dir would be nice > - Minor: a test utility for live dir would be nice If you use s6-rc, those are the same directories, filled by s6-rc-init and changed by s6-rc-update. So the test would actually test those utilities, I guess. [1] https://skarnet.org/software/s6/s6-usertree-maker.html --- Best regards, Peter
