Artix Linux Forum

Also, it seems that shepherd itself can't handle stage 1 scripts? But it's neat to see stage 1 scripts written in Guile. Though if I'm being cheeky, is it possible to write and run init and boot as guile/scheme shebang instead of shell?

Shepherd can handle stage 1, but it's not amazing for it; I found that having external scripts for stage 1 caused less friction. boot could absolutely be made as a guile shebang script; simple enough script to rewrite in guile. Also, at least on Void, stage 1 gets handled by externally scripts following a 00-99-scriptname pattern, though I'm not sure how exactly (or where) they're invoked by runit.

I'd probably need guidance for creating the materials needed for testing, as I can imagine it's very possible that my file layout isn't exactly how you all would prefer it on Artix; I know that Artix at least has different file/directory structure defaults for runit when compared to Void.

At the very least, stick to the defaults of shepherd (if it exists). Otherwise, your current defaults are good enough (though I'm curious where would you put services that are not enabled/active but installed). Runit's directory structure was somewhat of a mistake I made in the past but cannot be remedied anymore.

Well, by default, Shepherd's system level config file is expected to be at /etc/shepherd.scm, putting it at /etc/shepherd/config.scm was a personal liberty I took. I think a layout of:

Code: [Select]

/etc/shepherd/services.d # installed but not enabled
/etc/shepherd/enabled.d # installed and enabled

could work; using (ice-9 ftw)'s scandir to iterate the enabled directory but not the regular services one -- so long as any dependencies are properly listed in a services #:requirement '(dep dep2 dep3) parameter. Other than that, it's been a little while since I've used a Guix system to see how they do it by default.

Perhaps the stage 1 could just be consolidated into a transient/one-shot service for Shepherd, so that it could be invoked directly as init

Quote from: wreed – on 12 June 2025, 11:58:05

Well, by default, Shepherd's system level config file is expected to be at /etc/shepherd.scm, putting it at /etc/shepherd/config.scm was a personal liberty I took. I think a layout of:

Code: [Select]

/etc/shepherd/services.d # installed but not enabled
/etc/shepherd/enabled.d # installed and enabled

could work; using (ice-9 ftw)'s scandir to iterate the enabled directory but not the regular services one -- so long as any dependencies are properly listed in a services #:requirement '(dep dep2 dep3) parameter. Other than that, it's been a little while since I've used a Guix system to see how they do it by default.

Perhaps the stage 1 could just be consolidated into a transient/one-shot service for Shepherd, so that it could be invoked directly as init

Honestly, since I'm not well versed in Guile/Scheme and Shepherd directorial structure, I'll leave that to whatever you think best, but I just discovered this line, and can't help but think that since shepherd's socket will be put in /run, it must be mounted first as tmpfs and wouldn't it be unfeasible if shepherd directly runs as init?

But in any case, so that people can actually test your Shepherd-as-an-Artix-init implementation, you'll need:

• The Shepherd PKGBUILD itself (you can steal it from AUR)
• PKGBUILD of the rc (so the things inside system/etc/init.d in your git repo)
• Several test services, with oneshots, foregrounds, and backgrounds (if possible)

If you need any help, just ask.