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 · 2025-11-22 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 (2025-11-22 19:09:47)

EDX-0 · 2025-11-22 23:28:03

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.

yes i know that, hence why shed is currently flawed and needs to become the session process and be a compliant x-session-manager, to give an example think of say xfce, if you start x11 from a display manager like lightdm and select xfce it will run an x11 session with the program xfce-session as the session "leader" program, xfce-session exports all env vars, starts all session components (window manager, panel program, wallpaper setter, desktop manager (program that provides desktop icons)), starts the settings manager and then runs the xdg-autostart programs, then finally waits and stays running until you logout, reboot or poweroff, in the logout process xfce-session acts as a middleman and cleans after itself killing every process it started (or at least those it knows about), kills every one of it's child processes and then terminates, once the session leader is terminated x11 terminates and you get sent back to the display manager.

when starting from a tty and running startx, the last program specified in your .xinitrc (or .xsession in debian based distros) as exec will become the session process leader, an .xsession can export environment variables before execking the last program, but again say we use xfce, the last line of the .xsession wold be exec xfce-session and then again xfce-session will have all the responsability.

the flaw of shed is that it is not currently the program that starts the window manager, ie the window manager and every GUI program is not a child of shed and thus won't properly inherit it's environment, only the programs started by shed inherit shed's environment, the window manager runs as a sibling of shed, so programs started from within the environment of the window manager have the window manager's environment.

a dirty hack would be to have shed first export all it's environment to a plain text file, then have the .xsession load shed's environment file... but the real solution is still to implement session components so the window manager can be started by shed...

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.

how do you log out? by all means shedc logout should take care of cleaning after itself, if it doesn't then i gotta fix that.

stultumanto · 2025-11-23 18:35:43

Sorry if all the edits are confusing. I've been updating this as I troubleshoot the issue.

how do you log out? by all means shedc logout should take care of cleaning after itself, if it doesn't then i gotta fix that.

Aha, I missed the whole shedc logout thing. (Edit) I modified my startup to run shedc logout on exit. It's still not deleting the runtime dir under /tmp/1000-runtime-dir, though. There's an error in my ~/.xsession-errors referring to a different path that doesn't exist:

/home/<MY_USERNAME>/.local/bin/shedc: 44: cannot open /run/user/1000/GUISession9799/*.pid: No such file
 sending term to        *.pid

I don't have a /run/user directory at any point in the process.

Last edited by stultumanto (2025-11-24 06:21:31)

EDX-0 · Today 02:05:00

ah yes, sorry it took me until today but it should be sorta kinda solved-ish in master as of now.

by mistake i was using the hardcoded path of the XDG_RUNTIME_DIR instead of using the env var.... shedc should use the env var now

as for the env var, i added the option to have a shed.rc file inside ${XDG_CONFIG_HOME:-${HOME}/.config}/shed/conf, that file is just loaded as a script file so use with care, there you can set the variable SHED_ENV_EXPORT_LOC to a filepath that your user can write to, say if you are already setting and exporting the GUI_SESSION_PID var inside your .xsession then you should be able to define the var like so:

# this is just a suggestion that hopefully ought to work if you startx in multiple ttys
SHED_ENV_EXPORT_LOC="/tmp/shed_session_${GUI_SESSION_PID}/shed.env"

the shed.rc being a loaded "script" the variable substitution should just work with dash, yes the variable definition should end in a filename at the end of a path, no you cannot just give a path as it will break how it works, no there is no checking of werether the variable definition ends in a path or a file since this is THAT cobbled together.

as for the contents of the export file it would look something akin to this:

export XDG_RUNTIME_DIR="/tmp/1000-runtime-dir"
export XDG_SESSION_ID="67"
export GUI_SESSION_PID="42069"

this ought to let ya just load that file inside your .xsession right after starting shed and before launching the window manager, or at least i hope, otherwise you'll have to use an until waiter loop like this

until [ -f "/tmp/shed_session_${GUI_SESSION_PID}/shed.env" ]; do
    # 50 miliseconds
    sleep 0.050
done

. /tmp/shed_session_${GUI_SESSION_PID}/shed.env"

anyways sorry for shed being such a hacked together thing that works all the time like 60% of the time outside of my setup, the whole thing started as a pair of scripts i cobbled for myself to be part of my dotfiles until i broke it "free" from my dotfiles into it's own script that has only continued to grow at a snailpace cuz i'm the only moron working on it and i mean MORON cuz i don't see anyone else stupid enough to write such a piece of software in posix(-ish) compliant shell...

stultumanto · Today 02:50:34

Nice! I had wondered if something like that would work. I appreciate you sharing this stuff. I don't really know what would be the "correct" way to write an alternative session manager, but I don't see anyone else even trying right now.

EDX-0 · Today 03:19:51

hope it works in your setup, anyway i go back to my usual unemployed activities, play videogames while pretending i'm working on this one business idea thing that idk if will even work.

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 2025-11-22 09:43:03

Re: SHED init independient/agnostic user services

#14 2025-11-22 23:28:03

Re: SHED init independient/agnostic user services

#15 2025-11-23 18:35:43

Re: SHED init independient/agnostic user services

#16 Today 02:05:00

Re: SHED init independient/agnostic user services

#17 Today 02:50:34

Re: SHED init independient/agnostic user services

#18 Today 03:19:51

Re: SHED init independient/agnostic user services

Board footer