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.