SHED init independient/agnostic user services

EDX-0 · 2022-08-08 06:33:32

this is very much a work in progress, still testing some functions before i can consider i'm at v0.0.0 but at the current state you can get a good idea of how it works, while the client component is mostly ready i've been rewriting some functions of the daemon to be able to do "start all" and "start service_name" gracefully from the same function, anyway here is the codeberg repo, will create the mirrors on github and gitlab later.

more details on the readme

https://codeberg.org/eylles/shed

yes i DO gotta improve the wording of that readme.

EDX-0 · 2022-08-10 16:02:29

okay, now shed is on a working state i just have to really iron out the kinks, i'm already running it on my .xsession and did reload the session services, i would be really glad if anyone who has knowledge of sysvinit and init scripts take a look and comment on my approach.

Head_on_a_Stick · 2022-08-11 10:23:00

Interesting project, thanks for sharing.

I've not tried it yet but glancing over the code I noticed the XDG_CONFIG_HOME reference in shed — not all distributions set that variable explicitly so it might be best to fallback to the recognised default if it is not set:

ServicesDir="${XDG_CONFIG_HOME:-~/.config}"/shed/services

Reference: https://gitlab.freedesktop.org/xdg/xdg- … g-user-dir

And shellcheck.net noticed this in shedc:

Line 90:
  reload) killchilds "all"; printf 'reload\n' > "${GUISessionDir}/socket" ;;
                            ^-- SC2317 (info): Command appears to be unreachable. Check usage (or ignore if invoked indirectly).

I think it's because the killchilds() function has exit 0 at the end so the printf command won't be run afterwards. But I might be wrong.

Last edited by Head_on_a_Stick (2022-08-11 10:23:33)

EDX-0 · 2022-08-11 20:55:48

thanks, added the fallback for the XDG_CONFIG_HOME variable, haven't had the time to test that the reload function works as intended but will give it a try as soon as possible and correct it as needed.

EDX-0 · 2022-08-12 09:43:55

yep the printf didn't ran after the killchilds() function was done, that has been corrected now, also added a basic makefile, this combined with the reloading capability of shed working properly makes it easier to test changes and commit them as i go.

EDX-0 · 2022-08-22 03:10:00

ah well, a little status update for those interested in shed, i will put out a release tag once i'm done with another 3 points of the todo list on the repo.

as for showing the status i went for something that those acquainted with sysvinit will find familiar.

EDX-0 · 2022-10-02 08:28:03

the first version of shed, v.0.0.0 is finally out

https://codeberg.org/eylles/shed/releases

after this i plan to work on the rest of intended features, bash completion and a man page.

stultumanto · 2025-11-18 22:41:03

I wanted to give this a try, but it seems my system may be too minimal in its current state. Is this because I don't have elogind installed? Do I need it?

mkdir: cannot create directory ‘/run/user’: Permission denied
mkfifo: cannot create fifo '/run/user/1000/GUISession23383/socket': No such file or directory

EDX-0 · 2025-11-19 00:45:49

yes, the last release tag (0.2.0) expects you to have elogind OR something else that did define the XDG_RUNTIME_DIR, master since commit cc6d537 will define the XDG_RUNTIME_DIR and since commit 95d95c4 it will fallback to create an XDG_RUNTIME_DIR in a similar manner to the one that gentoo recommends to launch sway from a tty, additionally on linux (not really targetting other unixes at the time) it can also set the XDG_SESSION_ID

but all those are features i've added on master, the warning in the readme was because at the start of the development cycle for 0.3.0 i was breaking stuff more often, while you can do use master safely for now i still have to break more things to add the concept of "sessions" and "session components"

for shed will have to receive an argument specifiying the session name or it fallbacks to default, every session name, including default would be a subdirectory of the XDG_CONFIG_HOME/shed/sessions dir (will need to add fallback dirs for sessions bundled with shed, defined by vendor, defined by admin, and have the user config sessions have priority with falling back to each subsequent dir) where the name is the name of the subdir, each session will have to contain a loadable "session.rc" file that adds configuration and information about the session and how some processes ought to be started and treated, an optional "session.d" directory for other files (scripts) to load, then the "components" subdir for the session components and finally the "services" subdir for the session specific user level services to be managed by shed

the "session components" will be a class of services apart from the "user services" already understood by shed, in that these are meant to be core components of the session like the window manager, compositor, panel, notifications daemon, keyring daemon, etc... they differ in that this class will normally only get started on shed's first run and only get terminated on shed's logout but not touched during reload (when shed execs itself) nor to be touched by the regular stop, start, status and restart operations.

also gotta add support for oneshot services as right now shed assumes every service is a daemon...

those intended changes are so that shed can be used as a proper x-session-manager instead of a very hacked together thing shoved into the .xsession

that said, use shed from master without worry for the time being, just whenever you pull your local copy of the repo to update check the git log to see what (if any) has changed in order to adapt your setup as i continue to develop shed on the road for 0.3.0

stultumanto · 2025-11-19 03:29:47

OK, thanks. It didn't occur to me that the logic to handle XDG_RUNTIME_DIR being unset wasn't be in the release version. I will update to master and keep an eye on the log.

(Later edit) It's all working now. I cloned from master, ran make && make install, then confirmed shed was running. It automatically creates a runtime directory at /tmp/1000-runtime-dir/GUISessionXXXX each time the X server starts. I put the three PipeWire service files in ~/.config/shed/services/ as you showed in the other thread, and now they're starting as well. Now I'm thinking about what else it might be good for. I think I'll try creating a service for starting Deskflow. It's not quite as complicated to run as PipeWire (it doesn't need a socket, for example) but it would still be neater to use shed.

Last edited by stultumanto (2025-11-19 15:39:18)

coder-hase · 2025-11-19 17:29:35

Hello EDX-0, I like your shell approach and the idea of being agnostic of window system. init-system or whatever is there. (I'm using a similar thing for my own stuff on Raspberry Pi.) I have a small suggestion just in case there are distro maintainers with aversion of too much shell commands:

get_shed_cgroup_2() {
  awk '
        BEGIN {
                pid = ARGV[1];
                cmd = "ps ax -o pid,cgroup,cmd=CMD ";
                while (cmd | getline > 0) {
                        if ($0 ~ /grep/  ||  $0 !~ /shed/)
                                continue;
                        else if ($1 != pid)
                                continue;

                        sub(/^.*::\//, "", $2);
                        print $2;
                        }
                }' "$shed_pid"
        }

shed_pid=$$
get_shed_cgroup
get_shed_cgroup_2

EDX-0 · 2025-11-20 04:30:42

ah thanks coder-hase that is indeed a neat idea, but after some digging turns out that it can be done in a much, much shorter way...

get_shed_cgroup() {
  sed 's@.*::/@@' /proc/"${shed_pid}"/cgroup
}

also it doesn't matter that using /proc/ is a linux only thing since cgroups are also a linux only concept... so if anyone on the bsd world or in other unices like illumos wants to port shed over there will be the need to use another process property to set the XDG_SESSION_ID, the BSD jails seem to be the closest thing to cgroups in BSD but i dunno if that would be the correct property to use, nor i know if the BSD world or other unices would have interest in something like shed as it seems linux is the only unix-like stuck in the absolute obscurantism of obtuse software like systemd and the lack of a generic session process even when the x-session-manager has been a concept in debian for ages...

stultumanto · Today 09:43:03

EDIT: After posting the question below, I realized something potentially more important. The value of XDG_RUNTIME_DIR set by shed isn't being exported to the session. As a result, pipewire commands run in terminal windows (such as pactl & wpctl) don't work. If I manually export it as /tmp/1000-runtime-dir from my ~/.xsessionrc then everything works fine. I'm not sure why this happens, since I see in your code that shed explicitly exports the variable. Of course shed can't export the value, I should have realized a script can't export to its invoking script unless it's sourced. However, in this case, even sourcing doesn't work, probably because shed runs in the background and doesn't exit.

I noticed I was accumulating multiple GUISessionXXXX directories on repeated login/logout cycles, since shed was creating a new directory each time from the new PID. It all gets cleaned out on reboot, but the XDG spec says we're supposed to delete these directories between login sessions. Would it make sense for shed to delete the directory on exit if shed created it? I'm not sure whether there might be processes still trying to access this directory after shed exits, but I'm guessing if shed created it, then only shed services are using it.

Last edited by stultumanto (Today 19:09:47)

The officially official Devuan Forum!

#1 2022-08-08 06:33:32

SHED init independient/agnostic user services

#2 2022-08-10 16:02:29

Re: SHED init independient/agnostic user services

#3 2022-08-11 10:23:00

Re: SHED init independient/agnostic user services

#4 2022-08-11 20:55:48

Re: SHED init independient/agnostic user services

#5 2022-08-12 09:43:55

Re: SHED init independient/agnostic user services

#6 2022-08-22 03:10:00

Re: SHED init independient/agnostic user services

#7 2022-10-02 08:28:03

Re: SHED init independient/agnostic user services

#8 2025-11-18 22:41:03

Re: SHED init independient/agnostic user services

#9 2025-11-19 00:45:49

Re: SHED init independient/agnostic user services

#10 2025-11-19 03:29:47

Re: SHED init independient/agnostic user services

#11 2025-11-19 17:29:35

Re: SHED init independient/agnostic user services

#12 2025-11-20 04:30:42

Re: SHED init independient/agnostic user services

#13 Today 09:43:03

Re: SHED init independient/agnostic user services

Board footer