Add support for running not only as PID 1

[troglobit]

The process monitoring capabilities of Finit could be beneficial in use-cases other than just PID 1. One such example use-case is http://supervisord.org/

• Configuration in ~/.config/finit.conf, requiring use of finit_rcsd path
• Optionally configuration via -f path/to/.conf
• API socket in /run/user/$(id -u)/finit/socket
• Resource file in /run/user/$(id -u)/finit/.initrc

Note, this requires something similar to pam_systemd(8) to notify Finit of users logging in.

[aanderse]

i would get great use out of this feature off it existed

realistically is this on your roadmap at all?

[troglobit]

realistically is this on your roadmap at all?

It is, not short-term though. There's quite a few things I'd like to refactor and add support for, and since much of it will break backwards compatibility, it has been added to the 5.0 milestone.

[aanderse]

thanks for the information @troglobit

i will admit i have become quite interested in this excellent project of yours and it has filled a good chunk of my hobby time

purely for interest sake i would love if you could share any realistic development plans - to me it looks like the milestone issues you have cover other people's desires, not just yours... and since this appears to be at least partially a hobby for you too i don't expect those milestone issues too be something you work on

then again, maybe you just scratch itches as they come along and you don't have any hard plans or personal deadlines... in which case i will just enjoy new releases and features as they come 😄

thanks again!

[aanderse]

hey @troglobit i hate to ping on something like this but given how responsive you have been to all of my many other inquiries i thought it entirely possible that you simply missed my message/question above about your realistic development plans for finit

if you have any insight to share i appreciate, and if not then of course no worries - thanks!

[troglobit]

Cool project there, Finix, I like it! 💪 💯

Heh, I had missed this one! 😅 Sorry, but I get so many notifications ... now, regarding your inquiry. The only concrete plans that exist are the milestones. I have some reminders and notes to myself here and there, but nothing concrete. Finit was sprung out of a need at a previous company I worked at, when a friend and I left we created Infix, with Finit as its PID 1. So that's what mostly drives Finit development today -- requirements in Infix, customer requests, and when the team finds something in the system that could be done in a better way.

Sure, from time to time, users submit ideas and half-baked implementations that can spark sudden bursts of creativity and open up new opportunities that need exploring. I really want it all to fit together nicely and feel right to users and myself.

[aanderse]

i'm not asking for anything here... but since you seem to be capable of herculean tasks during your summer vacation, and since you have recently done some relevant work in #500... i thought i would just mention that the top request by finix users i have heard is "what about user level service management?"

feel free to ignore this comment... 😅

[troglobit]

Proposal, user services

Finit started as a regular user is an unprivileged per-user supervisor with the same .conf format, conditions, initctl (new -u flag), and same D-Bus API. Config is read from ~/.config/finit.conf and ~/.config/finit.d/, runtime state and sockets live under $XDG_RUNTIME_DIR/finit/. This covers the supervisord-style use case: start finit from a shell or a service, no login integration required.

A template finit@.conf starts finit as user %i, gated on the condition usr/session:%i, and a small pam_exec script raises that condition on login. The idea is to avoid any concept of "sessions"; no logind equivalent, no session or seat tracking, no per-session instances, no user D-Bus session bus, no socket activation, no XDG autostart. One deliberate design difference from systemd: logging out does not stop your instance. The shipped PAM hook only ever raises the condition; stopping on last logout is an opt-in recipe in the docs. Your tmux survives. "Lingering" is just a boot task that raises the same condition, no extra machinery.

The template, enabled per user with initctl enable finit@joe:

service finit:%i {
    description      = "Finit user instance for %i"
    runlevel         = "2345789"
    cond             = "usr/session:%i"
    user             = "%i"
    pam              = "finit-user"
    runtime-dir      = "finit-user/%i"
    runtime-dir-mode = 0700
    stop-timeout     = 15
    command          = "/sbin/finit"
}

The pam line is why this depends on the PAM sessions work in #500 landing first: the instance runs inside a real PAM session, so pam_limits applies and modules like pam_rundir/pam_elogind provide XDG_RUNTIME_DIR. Inside the instance everything works as expected: runlevels, conditions, templates, readiness notification, and initctl -u for control.

Feedback welcome (ping @aanderse), in particular on the no-stop-on-logout default and on what Finix and other downstreams would need from the packaged user-services layer.

[aanderse]

this sounds amazing! i think this would be the perfect setup for every headless system, as well as many graphical systems!

after logind conquered consolekit all innovation stopped in the space and we had years of stagnation... but things have recently been changing! i would like to briefly mention some new projects in the desktop space:

• turnstile, a session tracker which can integrate with service managers and integrate them into the desktop stack by managing their life cycle, including graphical applications and optional lingering
• sessiond, a ridiculously complete replacement for the (e)logind stack, with complete polkit integration, including
  • sessiond-uaccess management which grants the currently seated user temporary access to audio/video/input devices, integrating with device managers like keventd 🙂
  • and more relevantly to this issue... sessiond-hooks, a sessiond integration which can do things like launch service managers and integrate with the graphical stack and optional lingering

sessiond is a very important innovation in the desktop space... and i would love if finit and sessiond-hooks could work in perfect harmony! the biggest asks from finit user level service management on my part would be:

• make sure finit doesn't have hard coded requirement of being launched any specific way, like from finit system level service manager... i assume this would be the case regardless, but i thought i should mention it to make it explicit
• add a setenv subcommand to initctl so we can inject environment variables globally into a given users finit instance... like dinit has: dinit --user setenv WAYLAND_DISPLAY=wayland-1. this will allow users to inject important desktop relevant environment variables into their finit instance as the variables become available

hopefully this isn't too much to keep in mind... but if you were able to consider these things i believe finit as a user level service manager would be even more useful to finit users running a graphical stack

as always, thank you so much for you for your consideration and efforts @troglobit 🙇‍♂️

[troglobit]

Thanks for the thorough write-up @aanderse, much appreciated! 🙏 The pointers to turnstile and sessiond were new to me, great to see this space moving.

Good news: both of your asks fit the design.

1. No hard-coded launch path, confirmed. The finit@.conf template + PAM hook is just one shipped integration, not the mechanism. Anything that can start a process in a user context, sessiond-hooks, turnstile, or a plain shell, will be able to launch finit directly; SIGTERM stops it gracefully, so a session tracker owns the full lifecycle, including its own logout and lingering policy. The docs will state this explicitly.

2. Added initctl setenv to my TODO. Planned as initctl -u setenv NAME=VALUE, with unsetenv NAME and env to inspect: a global overlay that applies to services started after the call and survives initctl reload. Explicit assignments only, so no systemd-style import-environment and no per-service injection. Same for the system instance too, since it is the same code.

We'll do our best to make finit and sessiond-hooks play well together, keep the feedback coming! 🙌