66 User services

vixalien

Hello. I'd like to ask if it's possible to manage services for a specific user in a similar fashion to systemd.

Here are a few possible usecases:

starting pipewire as a user service for each user
starting udiskie for each user
fetching mail when a user logs in

I could see there are service directories ending with /user but it's not clearly explained how they work.

there are also some features that would be nice to have:

a PAM module that could start/stop user services as long as a user has a session with a command like 66 tree start user@<username>
it would be most helpful to store the enabled services in the user's home directory
allow enabling user services directly, without using instanced services hacks. ex: 66 --user enable pipewire. possibly also allow enabling services for other users when root doas 66 --user jack enable pipewire
the user services must be started/stopped per user (and not per session). i.e. in the case above, pipewire will run as long as there is one session for the given user, not each time the user logs in

eric

vixalien Here are a few possible usecases:

starting pipewire as a user service for each user
starting udiskie for each user
I could see there are service directories ending with /user but it's not clearly explained how they work.

So, handling user services is native with 66. To deal with your user service simply use 66 command with your regular user.
For instance, doing as root:

# 66 tree create test

create a tree named test for root user and so doing as regular user:

% 66 tree create test

create a tree named test for the owner of the process.
Each user have his own 66 folder at $HOME/.66. You will find a sub-directory service where you can declare services frontend file for your users.
I encourage you to read this documentation to get an overview of the folder structure of 66.

Frontend service file for user can be declare at three different places:

$HOME/.66/service
/etc/66/service/user
/usr/share/66/service/user.
For a same frontend file the first one in the list above take precedence. So, each user can declare his own service.

So for example, you can do (as regular user):

% 66 start pipewire

Obviously the pipewire frontend file need to be present on your system(pacman -S pipewire-66serv).

vixalien fetching mail when a user logs in

Create a service to send the mail. Enable your service for the user.

vixalien it would be most helpful to store the enabled services in the user's home directory

$HOME/.66/*.

vixalien allow enabling user services directly, without using instanced services hacks. ex: 66 --user enable pipewire. possibly also allow enabling services for other users when root doas 66 --user jack enable pipewire

As i said previously, any 66 command (except 66 boot) can be launch as regular user. So:

# sudo -u <user> 66 enable pipewire.

vixalien the user services must be started/stopped per user (and not per session). i.e. in the case above, pipewire will run as long as there is one session for the given user, not each time the user logs in

This is not explicitly depending on 66 but how you build your service ecosystem with 66. 66 works on mechanism not on policies. See next point below.

vixalien a PAM module that could start/stop user services as long as a user has a session with a command like 66 tree start user@<username>

This is implies user tracking and management. This is not the role of a service manager. The service manager should provide mechanism to handle user service. However, user tracking should be handled by "extra" program.
Anyway, 66 or 66-tools do not provide user tracker mechanism. This is planned and will be provided by an external program. This doesn't mean that you cannot accomplish such a thing with 66.
For instance, you can use the boot-user@(pacman -S boot-user@-66serv) service and get a configured 66 ecosystem for the user. So, service enabled by the user should start at graphic session execution time.
Or you can use program like turnstile to track user and start service at login time.
Or you can use program like utlogd to track and execute command through script at log on and log out time. Note, i am not happy with it, it not really intuitive, convenient and use UTMP instead of PAM. Don't get me wrong, it works pretty well but do not correspond of what i have in mind regarding user tracking system.
Strictly speaking in 66 point of view, you can also use a elogind service. Obviously, this is not valuable on Obarun.
As you can see, the implementation of user tracking will depends on you. 66 will not block you to make your service ecosystem as you want.

vixalien

eric To deal with your user service simply use 66 command with your regular user.

Ah! This was the missing piece. I'm more familiar with running systemd --user enable something, rather than just allowing the svc manager to enable the service based on what I'm currently logged in as.

To be honest, I don't know how I feel about this. I feel like the systemd way of adding --user is a bit more explicit, and I don't think I have read about this unique behaviour of 66 before.

eric So for example, you can do (as regular user):

So that means that to "start user services", one would simply need to run the following command or similar, not as root?

66 scandir start

Note that I'm not entirely familiar with what exactly a "scandir" is.

eric This is implies user tracking and management. This is not the role of a service manager. The service manager should provide mechanism to handle user service. However, user tracking should be handled by "extra" program.

Nice. The reason I was asking about PAM is because I believe that's what used by systemd to launch user services.

eric

vixalien So that means that to "start user services", one would simply need to run the following command or similar, not as root?

yes.
A scandir corresponds to a directory (/run/66/scandir/<uid>/ on Obarun) where services are supervised. So, when you launch the 66 scandir start, 66 will create a new directory (if not existing yet) at /run/66/scandir/<uid> where <uid> correspond to the UID of the current owner of the process. Then it begins supervising the services defined in that directory. If you take a look at this directory you will see symlinks pointing to directories and files needed to handle the service.

pramodvu

eric services defined in that directory

Plz also know that the scandir contains service definitions for s6-svscan in directory format, NOT 66 fronetnds. 66 frontends are in ${HOME}/.66/service/.

vixalien PAM ... I believe that's what used by systemd to launch user services.

User instances of systemd [and services started by them] are NOT in the login session.
Some info:
Here, the login system on systemd on my production/office system:

● session-3.scope - Session 3 of User pramodvu
     Loaded: loaded (/run/systemd/transient/session-3.scope; transient)
  Transient: yes
     Active: active (running) since Tue 2025-01-14 09:31:48 IST; 10h ago
 Invocation: 162cc1e733474e8e9f178eeabf3d1c61
      Tasks: 9
     Memory: 64.5M (peak: 104.9M, swap: 20.3M, swap peak: 20.4M, zswap: 3.6M)
        CPU: 366ms
     CGroup: /user.slice/user-1010.slice/session-3.scope
             ├─1529 /usr/bin/greetd --session-worker 12
             ├─1576 /usr/bin/kwalletd6 --pam-login 10 11
             └─1577 /usr/bin/startplasma-wayland

# Extra log output cut out for brevity
Jan 14 17:44:03 inspiron3511pvu systemd[1]: session-3.scope: Unit now frozen-by-parent.
Jan 14 19:48:21 inspiron3511pvu systemd[1]: session-3.scope: Unit now thawed.

The greetd session worker is greetd's helper which creates a new login session, and launches the process defined in Exec= in /usr/share/wayland-sessions/. It runs the command to start KDE plasma.

cat /proc/${PID}/sessionid [PID is in the above output] of the above 3 processes are exactly correct, i.e. 3.

But here, all other processes are started as systemd --user units.
cat /proc/$(pidof plasmashell)/sessionid[OR kwin_wayland OR whatever] and /proc/$$/sessionid and /proc/self/sessionid all have a different session... 4.

But, loginctl user-status:

pramodvu (1010)
   Since: Tue 2025-01-14 09:31:47 IST; 4h 10min ago
   State: active
Sessions: 4 *3
  Linger: no
    Unit: user-1010.slice
          ├─session-3.scope
          │ ├─1529 /usr/bin/greetd --session-worker 12
          │ ├─1576 /usr/bin/kwalletd6 --pam-login 10 11
          │ └─1577 /usr/bin/startplasma-wayland
          └─user@1010.service
            ├─app.slice
            # Rest of the tree

So the login session and the systemd-user session is NOT same.

Again, the systemd session

$ loginctl session-status 4
4 - pramodvu (1010)
  Since: Tue 2025-01-14 09:31:47 IST; 4h 11min ago
  State: active
 Leader: 1558 (systemd)
 Remote: no
Service: systemd-user
   Type: unspecified
  Class: manager
   Idle: no

and the login session:

$ loginctl session-status 3
3 - pramodvu (1010)
  Since: Tue 2025-01-14 09:31:47 IST; 4h 11min ago
  State: active
 Leader: 1529 (greetd)
   Seat: seat0; vc1
    TTY: tty1
 Remote: no
Service: greetd
   Type: tty
  Class: user
   Idle: yes since Mon 2025-01-13 20:02:16 IST ((null))
   Unit: session-3.scope
         ├─1529 /usr/bin/greetd --session-worker 12
         ├─1576 /usr/bin/kwalletd6 --pam-login 10 11
         └─1577 /usr/bin/startplasma-wayland

# Logs
Jan 14 17:44:03 inspiron3511pvu systemd[1]: session-3.scope: Unit now frozen-by-parent.
Jan 14 19:48:21 inspiron3511pvu systemd[1]: session-3.scope: Unit now thawed.

Some attributes:
Login session: [assigned to VT, but idle since only the starter is present]

$ loginctl show-session 3
Id=3
User=1010
Name=pramodvu
Timestamp=Tue 2025-01-14 09:31:47 IST
TimestampMonotonic=39793011
VTNr=1
Seat=seat0
TTY=tty1
Remote=no
Service=greetd
Scope=session-3.scope
Leader=1529
Audit=3
Type=tty
Class=user
Active=yes
State=active
IdleHint=yes
IdleSinceHint=1736778736567458
IdleSinceHintMonotonic=0
CanIdle=yes
CanLock=yes
LockedHint=no

And the systemd one [noVT, but non-idle since KDE runs here]

$ loginctl show-session 4
Id=4
User=1010
Name=pramodvu
Timestamp=Tue 2025-01-14 09:31:47 IST
TimestampMonotonic=39858917
VTNr=0
Remote=no
Service=systemd-user
Leader=1558
Audit=4
Type=unspecified
Class=manager
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
CanIdle=no
CanLock=no
LockedHint=no

So there is explicitly different sessions for the login and for the user-services. I ask the 66 devs @eric , to try using the same session instead of this.
Note: All attributes other than User, SID, VTNr, leader and maybe the name, is only in logind, NOT in the kernel, so don't worry about them in 66.

The separation is mainly due to the kernel's limitation of setsid(), where only the leader can only be launched into new sessions.

Se turnstiled, which solves this by making the session leader itself the user-service-manager.
But boot-user@ etc. should be handled differently.