Services for desktop environment

[markK24]

Hi, I'm trying to figure out what would be the best approach to start a wayland compositor (in my case, niri) with some background services (for example, swaybg). Ideally, packaging it and installing in system directories (/usr/lib/dinit.d/usert).

My best thought was having a niri service, which would just start niri, then create a niri.target service, which would depend-on niri and wait-for.d some directory where I could symlink background services.

I want the directory to be writable by the user, but the problem here is that waits-for.d does not support variable substitution (and as far as I understand, it is not planned), so I can't set it to something like ${HOME}/.config/dinit.d/niri.d.

Is there another approach that is preferred? Should I consider implementing variable substitution for directory paths? (Or at least implement paths relative to home directory - ~)? Or should I give up on the service based approach and just start the background programs through the compositor configuration? (Using spawn-at-startup)

Thanks for the advice.

[mobin-2008]

Hi.

I personally run my background apps with dinit. Here's my list (dinitctl list):

[[+]     ] boot
[{+}     ] system
[{+}     ] dbus (pid: 1215)
[{+}     ] pipewire-pulse (pid: 1223)
[{+}     ] pipewire (pid: 1221)
[{+}     ] wireplumber (pid: 1222)
[{+}     ] openrazer-daemon (pid: 1216)
[{+}     ] openrgb (pid: 1217)
[[+]     ] swaybg (pid: 1350)
[[+]     ] polychromatic-tray-applet (pid: 1352)
[[+]     ] waybar (pid: 1354)
[[+]     ] clipboard-manager (pid: 1356)
[[+]     ] mako (pid: 1358)
[[+]     ] nm-applet (pid: 1360)
[[+]     ] nextcloud (pid: 1362)
[[+]     ] polkit-agent (pid: 1364)
[[+]     ] swayidle (pid: 1366)

I run labwc with tuigreet. Labwc runs its autostart script. I have a list of services that should start in that file. Also, I will stop them in the shutdown script of labwc. I have the idea of replacing the custom array of services in the labwc autostart script with a single target that waits-for.d services I need in my DE (something that you will do).

Is there another approach that is preferred? Should I consider implementing variable substitution for directory paths? (Or at least implement paths relative to home directory - ~)? Or should I give up on the service based approach and just start the background programs through the compositor configuration? (Using spawn-at-startup)

I think the use of variable substitution for this, having a simple base for desktop sessions, is reasonable.

Process supervision and service management are really helpful for having a more robust system. Supervision is useful to make sure DE wouldn't collapse because a daemon died. The supervisor tries to restart the program for this purpose. Supervisor also makes managing daemons easier because it provides an interface to start/stop/restart a daemon or even send signals to it without using pgrep and solutions that have a high chance of race conditions. Service management is useful for having proper dependencies and having fast, robust startup. Overall, it's a good idea to use the proper tool for the job.

[davmac314]

My best thought was having a niri service, which would just start niri, then create a niri.target service, which would depend-on niri and wait-for.d some directory where I could symlink background services.

Just to be clear, those background services would likely need depends-on: niri for this to work correctly (and would also require that niri use some suitable readiness notification, for example). Trying to start something which needs a compositor running at the same time as that compositor is still starting up will likely cause problems.

I want the directory to be writable by the user, but the problem here is that waits-for.d does not support variable substitution (and as far as I understand, it is not planned)

I think you mean that you are not aware of plans to support it, rather than that you are aware that it is not planned? (If the latter, where does that information come from - do I need to update some documentation somewhere?)

It wasn't specifically planned, though I have some (as yet vague) plans to make service configuration more consistent.

Should I consider implementing variable substitution for directory paths?

That would likely be fairly straight-forward to do, and I have no objection.

Another option working right now is that the service description file for niri.target is written or copied to the directory with the user's service description files (eg ~/.config/dinit.d). The user niri.target file can even @include a system-specified niri.target file. Obviously this would require a little setup for each user, so I understand if you don't find it satisfactory.

[markK24]

I think you mean that you are not aware of plans to support it, rather than that you are aware that it is not planned? (If the latter, where does that information come from - do I need to update some documentation somewhere?)

Yes, that's what I meant. My phrasing should have been clearer.

Just to be clear, those background services would likely need depends-on: niri for this to work correctly (and would also require that niri use some suitable readiness notification, for example). Trying to start something which needs a compositor running at the same time as that compositor is still starting up will likely cause problems.

First, I checked and niri supports readiness notification via NOTIFY_FD variable, although it's not documented. (I guess I'll mention it there)

For the background services, I can see 4 possibilities there:

• If the package does not provide a dinit service at all (which I sadly expect to happen in most cases), then the service would be self-written by the user and they can specify depends-on: niri themselves.
• If the package provides a dinit service, but the service does not define any dependency, it is possible to create a user service with the same name which @includes the provided one, and specifies the dependency.
• Background services use depends-on: graphical-session.target which is provided by some package/distribution, which itself depends-on: $GRAPHICAL_PROVIDER which can be imported into environment by the login manager (session startup script/somthing like that). The disadvantage here is it requires cooperation between background service developers/packagers and compositor developers/packagers, so I don't see it happening.
• Background services use depends-on: $1 and then a user can just dinitctl enable --from niri.target swaybg@niri.

That would likely be fairly straight-forward to do, and I have no objection.

I'll try to implement that in the coming days then. Thanks.