SHED

A manager for user services and session process

Follow the shed development and feedback threads:

what?

Session services, 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

The eventual intention is to not just implement user services but also the spec of the x-session-manager as defined (altho loosely) by debian.

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 units and runit user services as they don't support restarting for 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 and desktop environment, potentially even agnostic to any graphical environment (altho i personally only care or x11)

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

pending

• add support for oneshot type services that only run and then exit
• move service .pid files to their own subdir inside GUISessionDir
• 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 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

DO NOT USE THE GIT MASTER EVER! or maybe DO!

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...