User Services

[navi-desu]

Hello! This is the start of a draft for supporting user services.

The current "design" works by basically mimicking the layout of the system services.
This commit is the start of the proof of concept, based on what was talked on #432.

I'm opening this draft PR early to ask for some comments and a bit of guidance (since is this my first patch contributing to any project!), and to track progress of the feature.

The current implementation for paths is not that great IMO but I failed to think of a better one.
This also only includes librc, some other utilities are accessing the define'd variables and thus are broken in this patch, but I was able to get rc-update and rc-status, and to an extend, rc-service too, working as things is (granted I created the files in .config manually).
Once a better implementation is decided (or if this one is deemed ideal) I'll patch every file needed and run the tests properly.

The current implementation checks for the callers euid in order to toggle to user mode. If this is not desirable, we could instead introduce subcommands or flags in the commands themselves (rc-update user add <service> for example)

I am also still not familiar with openrc-run, so more study on that and the possible syntax for user service files is needed.

In resume, the idea is to have user-specific runtimes, limited to the users home folder, and tracked by the user (either via PAM, by running the openrc command manually to set the runlevel or other method).

If this feature is wanted, I'm willing to keep developing it and maintaining it for as long as necessary.

Signed-off-by: anna [email protected]

[andy5995]

Hi @anna-cli. One major problem I see is that memory is allocated each time the function is called, but never freed. Or did I miss something?

[navi-desu]

Hi @anna-cli. One major problem I see is that memory is allocated each time the function is called, but never freed. Or did I miss something?

Hello @andy5995! It shouldn't allocate more than once per function (since the
pointers are global, and there's the check before allocation). But you
made me realise that is probably better to just declare the string as a
static char array inside the function!

[N-R-K]

Looking at #432 I don't see any of the maintainers making any comment on whether this feature is desired or not.

But just glancing over the diff, I see a decent amount of things which I do not like. I figured I'd leave my comments in here.

But keep in mind that I'm not a maintainer here, so for some of my "larger design related" comments, you probably should wait for a maintainer to comment before acting on it.

[navi-desu]

Hello again! Last two days I rewrote the whole patchset, and I think it is ready for review! (although there's probably a few mistakes left still).

[navi-desu]

@dwfreed @williamh @vapier (CC @thesamesam), Hello! sam recommended I tag one of you, could you check this PR? If it is a desired feature, and if the code overall looks okay!

I am currently daily driving the the patches and looking for bugs and if everything is working too.

[navi-desu]

Easy way to test on gentoo:

• Add EGIT_OVERRIDE_REPO_OPENRC_OPENRC="https://github.com/navi-desu/openrc" to your make.conf
• emerge -1 "=sys-apps/openrc-9999"
• Some example scripts are available in here, they should go in ${XDG_CONFIG_DIR}/init.d (defaults to ~/.config/init.d), config files go in ~/.config/conf.d, and the runlevels are created at ~/.config/runlevels. (System-wide services, installed by the package managers will go in /etc/init.d/user.d and /etc/conf.d/user.d)
• Then just use normal rc-* commands with the --user flag (or -U). openrc --user default to start the default runlevel (created automatically)

[NyaomiDEV]

This is great! However, have you had any problems with services using D-Bus at all? How would you handle environment exports like that? I am asking since stuff like PipeWire requires it to properly function.

[navi-desu]

This is great! However, have you had any problems with services using D-Bus at all? How would you handle environment exports like that? I am asking since stuff like PipeWire requires it to properly function.

for the scripts i wrote so far, only wireplumber needs dbus, a hack to make it work is setting 'rc_env_allow="DBUS_SESSION_BUS_ADDRESS"' in .config/openrc/rc.conf, tho this won't really work when the runlevel is started via PAM (which would be the ideal way to handle that imo).

one thing i'm thinking is making a user init script for a dbus user session, that could be a step to allow the services to see dbus, tho i'm still not sure how to get the var from that into the env of other scripts

[NyaomiDEV]

one thing i'm thinking is making a user init script for a dbus user session, that could be a step to allow the services to see dbus, tho i'm still not sure how to get the var from that into the env of other scripts

That's the problem. You should preemptively export DBUS_SESSION_BUS_ADDRESS upon user login to a known value (hint: unix:path=$XDG_RUNTIME_DIR/bus) and then make dbus.user use that environment variable as the path to place the socket (also, being a PAM module I think it'll run early enough that desktop environments can see it, tho my brain is a bit rusty so it's just better to test that hypothesis.)

Now, as for the how, it's up to you; I think you can place it in rc.conf.

---

Also yes, an accompanying PAM module might be beneficial to the PR. I would suggest looking at https://github.com/chimera-linux/turnstile/blob/master/src/pam_turnstile.cc

[navi-desu]

superseded by #723 for the sole reason of github doesn't let me change the source branch of a pr (seriously gh??)