SHED init independient/agnostic user services

EDX-0 · 2026-03-17 00:55:33

was just noticing, the current development cycle of shed v0.3.0 constitutes more than half of the total commits to shed and yet i've barely made a dent on the pending side of the roadmap... most of the commits have been either tangentially unrelated to the roadmap or refactors and improvements over early poor design decisions when i barely had a concrete vision of what shed was supposed to be...

coder-hase · 2026-03-21 09:07:28

Yor are right, EDX-0, pico-init has become large (it's no longer "pico"). I see two major scenarios where it fits:

as pidN service controller/supervisor if the use case is strong enough (e.g. for a Rasperry Pi gadget device) or
as experimental or test kit for processes control: as soon as you know what you want and need you would copy&paste idea and/or code to your project.

Just yesterday I got an idea for a possible scenario 2 .

EDX-0 · 2026-03-21 09:54:19

@coder-hase ya could always look into "breaking up" components form pico-init to a collection of smaller utilities, ya know to cheat the whole line count.

as for shed i've been working on it and i'm quite satisfied that many of the commits from this week have incurred in deduplication and generalization of code as that has vastly cleaned up the project.

coder-hase · 2026-03-22 10:22:17

I took a look at shed (version shed.v0.2.0-120-gd7af2d4) to see how you manage is processes are running. I guess I made something completely wrong due to my impatience or missing experience with gaming X sessions. Nevertheless, I got what I already suspected. shed was reporting that is was already running (line 142) when that was really not the case. It's because shed relies on pidfiles only. (If there is one single thing I should name that was giving me most issues with SysV init then it is the reliance on pidfiles in the "early"? init scripts.)

Instead you could use start-stop-daemon, and if that's not installed busybox start-stop-daemon (busybox is widely used in Linux installations because of its use in initrd) but (1) I have no idea about non-Linux UNIX systems and (2) I don't think that it would help in checking for the shed script.

Here is a suggestion for some "stuff" that might work too.

#!/bin/sh
#

is_running() {
    /usr/bin/awk '#

	function getarg(name,   p) {
		if (argi >= ARGC) {
			printf ("%s: missing arg: %s\n", program, name) >>"/dev/stderr";
			exit (1);
			}

		p = ARGV[argi];
		ARGV[argi++] = "";

		return (p);
		}

	BEGIN {
		program = "is-running";
		argi = 1;

		pidfile = getarg("pidfile");
		pid = getarg("pid");

		if (pidfile != ""  &&  pidfile != ".") {
			getline pid2 <pidfile;
			close(pidfile);
			if (pid == ""  ||  pid == ".")
				pid = pid2;
			else if (pid != pid2)
				exit (1);
			}

		fn = "/proc/" pid "/cmdline";
		FS = "\0";
		getline <fn;
		close (fn);
		for (i = 1; ARGV[argi] != ""; argi++) {
			if (ARGV[argi] == ""  ||  ARGV[argi] != $(i++))
				exit (1);
			}

		exit (0);
		}' "$@"

	return $?
    }

is_running "$@"
exit $?

is_running is a draft of a shell function *relying on /proc* (again: don't know about non-Linux) accepting 3 or more parameters:

the name of the process' pidfile; this is optional
the process' pid; optional: if pidfile is given its value is compared against pid and they are expected to match; if missing the pidfile's content is used as pid
the process' executable (optional - if not set only pids would compared but that would not make much sense for this function)
addtional optional parameter would be compared against the process' command line parameters.
Arguments for process executable or parameter might be empty string to ignore the for comparison.

So, how could that been used in shed? Just guessing here, but testing for a running service should be

is_running $pidfile "" $EXEC

but that does not work for interpreted scripts (bad). Adding `$E_ARGS` should help

is_running $pidfile "" $EXEC $E_ARGS

but the script's `$EXEC` must be the interpreter (i.e. no use of `#!` here).
Also

is_running $startfile "" /bin/sh shed

should check if shed is running. You can replace `/bin/sh` with `""` if you are unsure about the shell interpreter.

EDX-0 · 2026-03-26 02:48:59

yeh, i know that the way i'm using pid files is not the best, cleanest or even most reliable, i did have my eyes set on leveraging the start-stop-daemon program early on but decided against it at the start of the project as a proof of concept to see if i could get away without as a dependency, i do want to add use of start-stop-daemon to shed before the v0.3.0 release but as a soft dependency rather than a hard one, as in "do we got 'start-stop-daemon'? yes we do, that will be used and things will be more reliable. no we don't but we can fallback to the less reliable shell backend, that is okay." rather than "ya didn't install 'start-stop-daemon' in this thing? lol get rekt nothing works lmao"

as a sidenote, maybe i should try passing shed as a suckless program, say label it like a "suckless session process", perhaps it would generate more interest that way...

EDX-0 · 2026-04-01 05:56:50

well oneshots are finally handled reliably and i think every part of shed that needed to be refactored in preparation for session components has been refactored, i'll work on the session components tomorrow and making shed a more proper x-session-manager, i feel tempted to cut the release for shed v0.3.0 at just being able to use shed as an x-session-manager that works for minimal x11 pseudo-desktops, ie; environments built upon window managers and independent components much in the style of the bunsenlabs desktop, antix, miyo and mabox, cuz adding support for stuff like wayland and more traditional desktop environment setups requires a lot more work like introducing the architecture of "shed shallow" -> "gui leader" - "shed transient", which for example in a wayland setup would be:

a "shallow" shed instance, which just sets up the environment vars like the XDG_RUNTIME_DIR if needed, loads the user profile into the environment if indicated, then proceeds to write it's pid onto a file and export it as the SESSION_LEADER to then exec the wayland compositor from the corresponding session component definition file, so that the wayland compositor can become that PID.

the wayland compositor then comes, does the setting of GUI environments it requires to do, starts a new shed instance within it's environment.

the "transient" shed instance then writes it's own pid at the shed.started file and continues starting all the other session components and services needed for completeing the session.

but yeh that is a workload i'm considering leaving for the v0.4.0 dev cycle, anyway onto my videogames i go

EDX-0 · Today 14:39:59

the state of shed as of today, year 2026, month 04 (april) day 10

this is to address what works, which features ara available and how shed can be used as of the latest commit to master (c4f77b1), what is still to be implemented, what features does shed need and also as a request for feedback from prospective users to gather interest on either cutting a release of shed this week or wait until more capabilities are implemented, any further commits pushed today to the repo will only be documentation related.

What shed can do right now:

shed can run as the x session process leader, that is if you use startx to start your x11 session from tty your .xinitrc (or .xsession in debian and all derivates) file can perfectly well be just a shebang with the line "exec shed" right below, shed will work as the session process and so long as you logout with "shedc logout" the session will be terminated correctly.

shed can also be used as the session process for a wayland session, however i'm barely versed in wayland beyond the minimum needed to make shed into something that can work for the architecture of how a wayland's session leader is not just their window manager but their compositor and actual windowing server.

that said in the current state both x11 and wayland sessions can be started from a display manager like sddm just needing the correct .desktop files to be provided, for example:

the current shed x11 session could be /usr/share/xsessions/shed.desktop

[Desktop Entry]
Name=shed
Comment=an x11 session in shed
Exec=shed
Type=Application

the current shed wayland session could be /usr/share/wayland-sessions/shed.desktop

[Desktop Entry]
Name=shed
Comment=a wayland session in shed
Exec=shed
Type=Application

of note to the interest of wayland users, as far as i know shed is the only tool out there that can be a viable alternative to the Universal Wayland Session Manager (UWSM), which is the only other generic tool for managing wayland compositors and it does so with systemd units.

current capabilities of a shed session daemon are:

set XDG_RUNTIME_DIR - meaning you can even run without elogind, just shed.
set XDG_SESSION_ID - the only feature so far that CANNOT be used as is in *BSD as it gets the session id from cgroups
set XDG_SESSION_DESKTOP and XDG_CURRENT_DESKTOP - env vars used to identify the desktop environment AND xdg-portals config for using the xdg-portals
set xdg home dirs - the XDG_DATA_HOME as $HOME/.local/share, XDG_CACHE_HOME as $HOME/.cache, XDG_STATE_HOME as $HOME/.local/state, not to mention XDG_DESKTOP_DIR, XDG_DOWNLOAD_DIR, XDG_TEMPLATES_DIR, XDG_PUBLICSHARE_DIR, XDG_DOCUMENTS_DIR, XDG_MUSIC_DIR, XDG_PICTURES_DIR, XDG_VIDEOS_DIR, defined with xdg-user-dirs-update, worth mentioning that for this purpose shed only exports their ENV var values it however does not initialize (mkdir) the directories as that step is not a strong requirement imposed on all session processes as far as i know.
can also export an "exports" file in shell loadable format containing the values of XDG_RUNTIME_DIR, XDG_SESSION_ID and shed's own SHED_SESSION_PID, this was an option that previously could be a requirement back when shed could not run as the session process, i'm keeping it for the time being as an option that may be of use to someone tho removal of this capability is open to possibility.

besides the configuration file shed supports:

loading of .env files to set up the environment during session initialization and before starting of components and services, .env files are just posix compliant shell scripts (no bashisms) which are to be stored in ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/shallow.d for the files to be loaded during the shallow phase and ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/env.d for the ones to be loaded during the transient phase, shed will only ever load them during the initial run as loading of .env files is ignored during reloads such as when calling shedc reload and shedc relaunch.

starting session components, session component definitions are stored in ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/components, session components are services that will only be started at session start and terminated upon logout, meaning no attempt is made to start them from shed re-executions.

starting and managing user-services, one of the main reasons i wrote shed and the core functionality that was extended to session components, service definition files are stored in ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/services, oneshot and daemon type services are supported, worth mentioning that with daemon type services the called program must NOT fork to background and exec to daemonize itself, such behaviour breaks the way that shed manages services, i know sysvinit in debian has no problem with that thanks to leveraging start-stop-daemon but shed does not use that program instead going for pure shell in hopes of portability.

do a shallow to transient initialization process in which shed starts in shallow mode only setting up the environment, then checks for a "transient" script which should be executable, if the check succeeds the script is ran with exec allowing it to inherit the PID of the shed instance, then it has to execute the program that will become session leader (also with exec so it inherites the session pid) and then the program has to launch a new instance of shed as a child, if the check fails shed will simply execute itself again, at this point execution of shed converging and completeing the session by starting session components and user services

what shed cannot do:

start programs from the xdg-autostart spec, in theory user services are better as they are explicit with their lifecycle behaviour (daemon or oneshot), tho a way to support xdg-autostart entries would be to run a script to parse and convert them into the shed service definition format, an additional feature would be required from shed when starting services to keep polling on the pid for a while and checking the exec name and flags to ensure it is the same program and so determine if it is a daemon or was a one shot, for that reason i did not have support for xdg-autostart as a goal for release v0.3.0 from the start of the development cycle.

use a proper implementation of the XDG_CONFIG standar, in fact shed only supports to have ONE set of configurations for ONE session, changes are planned to re-structure the shed configuration from:

$XDG_CONFIG_HOME/shed/
|- shed.rc
|- shallow.d/
|- env.d/
|- components/
|- services/
|- transient

to:

/etc/shed
|- sessions/
   |- session_name/
      |- shed.rc
      |- shallow.d/
      |- env.d/
      |- components/
      |- services/
      |- transient

$XDG_CONFIG_HOME/shed
|- sessions
   |- session_name      
      |- shed.rc
      |- shallow.d/
      |- env.d/
      |- components/
      |- services/
      |- transient

as this schema would allow for distributors to ship sessions, say if tomorrow someone wanted to create their own "desktop environment" using shed, say it was named Joe's Desktop Environment, and it was to use pekwm, picom, pipewire, xfce-polkit, and betterxsecurelock, then the default files that would be shipped for that session would be:

/etc/shed
|- sessions/
   |- JDM/
      |- shed.rc
      |- shallow.d/
      |- env.d/
         |- xrdb.env
      |- components/
         |- 99x11-windowmanager
      |- services/
         |- compositor
         |- pipewire-daemon
         |- pipewire-daemon-pulse
         |- pipewire-media-session
         |- polkit-agent
         |- xscreenlocker

however i'm very tempted to make the release of shed v0.3.0 and just leave these pending features for the dev cycle of v0.4.0 as i personally have no use for them and so far i feel shed has not gained enough traction to justify working on them.

The officially official Devuan Forum!

#26 2026-03-17 00:55:33

Re: SHED init independient/agnostic user services

#27 2026-03-21 09:07:28

Re: SHED init independient/agnostic user services

#28 2026-03-21 09:54:19

Re: SHED init independient/agnostic user services

#29 2026-03-22 10:22:17

Re: SHED init independient/agnostic user services

#30 2026-03-26 02:48:59

Re: SHED init independient/agnostic user services

#31 2026-04-01 05:56:50

Re: SHED init independient/agnostic user services

#32 Today 14:39:59

Re: SHED init independient/agnostic user services

Board footer