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 · Yesterday 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 · Today 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 · Today 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 (Today 15:39:18)

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 Yesterday 22:41:03

Re: SHED init independient/agnostic user services

#9 Today 00:45:49

Re: SHED init independient/agnostic user services

#10 Today 03:29:47

Re: SHED init independient/agnostic user services

Board footer