SHED

A generic session process and init-agnostic user services provider.

Follow the shed development and feedback threads:

what?

A session process, like lxsession or xfce4-session, plasma-workspace, etc... but completely generic, not tied to any toolkit, desktop, windowing system or even to a graphical interface at all.

Session services, are programs that run as part of your graphical session, for example in x11 you have the compositor, keyring, maybe a clipboard daemon and perhaps pulseaudio or pipewire

dependencies

• a posix compatible shell interpreter
• core unix utilities (date, mkdir, awk, kill, mkfifo, cat)

why ?

Some programs have the tendency to missbehave when started in a session process in non systemd distros, the prime example right now being pipewire which has spawned this pipewire #1099 and this pipewire #1135 as the issue comments say, this problem forced gentoo to write a wrapper and slackware to roll out a custom daemon program written in C, in my opinion both of these solutions are less than ideal, on gentoo's case they now have to roll out similar wrappers for other missbehaving programs, the slackware program looks unnecessarily overengineered as it still needs more programs to be started correctly.

And the elephant in the room, both these solutions come out as inferior to the likes of systemd user units and runit user services as they don't support restarting or reloading configurations nor a correct way for them to be started and stopped by the user.

That is why i came up with this solution that takes a lot of inspiration from the sysvinit architecture with the aim of keeping simple, intuitive and completely agnostic from any window manager, desktop environment, and even to any graphical environment as it's architecture should have not problem whatsoever handling x11, wayland, arcan, tty, ssh, etc... thanks to how it was designed and written in almost exclusively portable POSIX shell with some awk and just 1 function that relies on a linux kernel feature.

This program is something that should have been written 10, 15 maybe even 20 years ago by someone much smarter but it was only when i could no longer bear the situation of there being no generic program with the capabilites of shed that i forced myself into writing it.

ROADMAP

done

• move the details of how shed works to another .md file
• add check if the service is running in start, kill and hup
• add service status action to shedc
• add service restart action to shedc
• add a shed daemon reply socket, so that shedc can wait that shed is reloaded.
• make shedc tail and read the reply socket
• introduce libshed for shaded code between shed and shedc
• add info action to shedc to show info of the running shed daemon
• move service .pid files to their own subdir inside GUISessionDir
• add support for oneshot type services that only run and then exit
• add a session cathegory of services that are not affected by actions (start, stop, restart) sent to all nor by reloads of shed, so that stuff like window managers can be managed on this cathegory
• implement the shed_shallow->transient-shed_instance architecture, where in a "shallow" shed instance sets the environment, executes the transient process and later on the transient spawns a shed instance as a child process, this architecture is required to support wayland sessions.
• added checks for a fallback dir in /etc/shed for configs not present in XDG_CONFIG_HOME/shed so they can be loaded from there instead

pending

• Implement per session configs, that is to have the set of files and subdirs which currently reside in XDG_CONFIG_HOME/shed and their fallbacks at /etc/shed to reside inside a subdir sessions/session_name where the session_name would be akin to the XDG_CURRENT_DESKTOP, to use the configs for a given session the session start will require to have shed called with the shed session_name as argument, this will allow users to be able to maintain multiple session configuration sets allowing not just managing 1 window manager or 1 wayland session but having multiple definitions for either, this will also open the door for future distributors to provide multiple shed managed sessions for x11 or wayland
• implement the XDG_AUTOSTART spec and provide the option to start and manage services from the autostart as regular ones.
• write bash completion scripts
• write zsh completion scripts
• draw a logo/icon for shed to use in the repo

use the git master but beware of changes!

Currently the master branch functions in a more consistent way than the stuff in the release tags do but it isn't really a stable work per se and things may break without notice altho i do try to test all commits before pushing i do not know what your config and setup are like so if you have an issue, bug or something broke specify you used the master branch and not a release tag, i tend to use changes that have not yet been merged to master first cuz i develop this for myself as target audience second cuz it will break on my machine first before breaking on someone else's, hopefully... still read the commit history after pulling the repo and before running make!

LICENSE

All files in the repo are licensed under GPLv3.0 or later