Continuing this tutorial series on service files, today we’ll look at a simple, comparable way to make “user services” available in Nitrux. OpenRC did not have a concept of “user services” as defined by Systemd, “systemd offers users the ability to manage services under the user’s control with a per-user systemd instance, enabling users to start, stop, enable, and disable their own units“. However, OpenRC now supports user services starting with version 0.60; user service scripts are loaded from /etc/user/init.d/, and user configurations are located in /etc/user/conf.d/.
But we’ll do it in a much simpler, rootless way.
Difficulty: ★☆☆☆☆
Services as a User?
Most users are familiar with the system-wide services managed by the init-system; think of your packaged Docker daemon or the PulseAudio server. Regular services on Nitrux are usually located in /etc/init.d and run with root privileges. These services have one thing in common: once enabled, they start and stop with the system boot and shut down, depending on their runlevel.
But a “service” can be made for and entirely controlled by regular unprivileged users. We can achieve this by using a set of standardized paths, not specific to any init system, called the XDG Autostart Specification.
What is XDG Autostart?
The Desktop Application Autostart Specification, or XDG Autostart as it’s more commonly known, is a Freedesktop specification that “defines a method for automatically starting applications during the startup of a desktop environment […].” The XDG Autostart directories, in order of preference, are:
- User-specific:
$XDG_CONFIG_HOME/autostart(~/.config/autostart).
How do you use XDG Autostart to create “user services”?
You may wonder how this is comparable to the implementation in the Systemd software suite. First, we should understand the real reason for having user services. We must realize when the enabled service starts and stops to answer that. If we enable a “user service,” it starts at user login and runs until the user’s session ends. Once the last session dies, the service stops.
The significant advantage is that the user can manage this service without sudo.
Since Nitrux 5.0.0, we’ve been using Hyprland, which works differently in this regard. Instead of adding a desktop launcher to the mentioned directory as we’d do for other desktops, like Plasma, we only add the executable we want to autostart to the configuration file in ~/.config/hypr/hyprland.conf, like this.
################# ### AUTOSTART ### ################# # Autostart necessary processes (like notifications daemons, status bars, etc.) # Or execute your favorite apps at launch like this: exec-once = waybar
Once we log out and log in, the executable will run when the session starts.
That’s it; this concludes today’s tutorial and this series about user services in Nitrux.