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 replied to this.
    • Edited

    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.

      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 replied to this.
        • Edited

        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.

        Powered by Obarun