The officially official Devuan Forum!

EDX-0

Member

Registered: 2020-12-12

Posts: 223  

Re: SHED init independient/agnostic user services

was just noticing, the current development cycle of shed v0.3.0 constitutes more than half of the total commits to shed and yet i've barely made a dent on the pending side of the roadmap... most of the commits have been either tangentially unrelated to the roadmap or refactors and improvements over early poor design decisions when i barely had a concrete vision of what shed was supposed to be...

coder-hase

Member

Registered: 2025-08-11

Posts: 6  

Re: SHED init independient/agnostic user services

Yor are right, EDX-0, pico-init has become large (it's no longer "pico"). I see two major scenarios where it fits:

• as pidN service controller/supervisor if the use case is strong enough (e.g. for a Rasperry Pi gadget device) or

• as experimental or test kit for processes control: as soon as you know what you want and need you would copy&paste idea and/or code to your project.

Just yesterday I got an idea for a possible scenario 2 .

EDX-0

Member

Registered: 2020-12-12

Posts: 223  

Re: SHED init independient/agnostic user services

@coder-hase ya could always look into "breaking up" components form pico-init to a collection of smaller utilities, ya know to cheat the whole line count.

as for shed i've been working on it and i'm quite satisfied that many of the commits from this week have incurred in deduplication and generalization of code as that has vastly cleaned up the project.

coder-hase

Member

Registered: 2025-08-11

Posts: 6  

Re: SHED init independient/agnostic user services

I took a look at shed (version shed.v0.2.0-120-gd7af2d4) to see how you manage is processes are running. I guess I made something completely wrong due to my impatience or missing experience with gaming X sessions. Nevertheless, I got what I already suspected. shed was reporting that is was already running (line 142) when that was really not the case. It's because shed relies on pidfiles only. (If there is one single thing I should name that was giving me most issues with SysV init then it is the reliance on pidfiles in the "early"? init scripts.)

Instead you could use start-stop-daemon, and if that's not installed busybox start-stop-daemon (busybox is widely used in Linux installations because of its use in initrd) but (1) I have no idea about non-Linux UNIX systems and (2) I don't think that it would help in checking for the shed script.

Here is a suggestion for some "stuff" that might work too.

#!/bin/sh
#

is_running() {
    /usr/bin/awk '#

	function getarg(name,   p) {
		if (argi >= ARGC) {
			printf ("%s: missing arg: %s\n", program, name) >>"/dev/stderr";
			exit (1);
			}

		p = ARGV[argi];
		ARGV[argi++] = "";

		return (p);
		}

	BEGIN {
		program = "is-running";
		argi = 1;

		pidfile = getarg("pidfile");
		pid = getarg("pid");

		if (pidfile != ""  &&  pidfile != ".") {
			getline pid2 <pidfile;
			close(pidfile);
			if (pid == ""  ||  pid == ".")
				pid = pid2;
			else if (pid != pid2)
				exit (1);
			}

		fn = "/proc/" pid "/cmdline";
		FS = "\0";
		getline <fn;
		close (fn);
		for (i = 1; ARGV[argi] != ""; argi++) {
			if (ARGV[argi] == ""  ||  ARGV[argi] != $(i++))
				exit (1);
			}

		exit (0);
		}' "$@"

	return $?
    }

is_running "$@"
exit $?

is_running is a draft of a shell function *relying on /proc* (again: don't know about non-Linux) accepting 3 or more parameters:

• the name of the process' pidfile; this is optional

• the process' pid; optional: if pidfile is given its value is compared against pid and they are expected to match; if missing the pidfile's content is used as pid

• the process' executable (optional - if not set only pids would compared but that would not make much sense for this function)

• addtional optional parameter would be compared against the process' command line parameters.

• Arguments for process executable or parameter might be empty string to ignore the for comparison.

So, how could that been used in shed? Just guessing here, but testing for a running service should be

is_running $pidfile "" $EXEC

but that does not work for interpreted scripts (bad). Adding `$E_ARGS` should help

is_running $pidfile "" $EXEC $E_ARGS

but the script's `$EXEC` must be the interpreter (i.e. no use of `#!` here).
Also

is_running $startfile "" /bin/sh shed

should check if shed is running. You can replace `/bin/sh` with `""` if you are unsure about the shell interpreter.