General Category => Discussion about Artix => Topic started by: wreed on 09 June 2025, 20:16:33
Title: GNU Shepherd proposal
Post by: wreed on 09 June 2025, 20:16:33
Hello,
I have a working setup of GNU Shepherd running as a replacement to Runit on Void Linux. I wanted to reach out in the Artix community to see if you all might be interested in GNU Shepherd. I put together a repository of the resources I've gathered to make it run, as well as a number of example service definitions (at both the system and user levels). Devuan currently has Shepherd listed as being in consideration for adoption, which is where I got it to work first, however I went to Void (for reasons of familiarity) to try fully implementing it while also documenting the process. It's development has been quite impressive since it's 1.0.0 release, and it's really a treat to use in my opinion.
To see the resources I put together, you can see my github repository here (https://github.com/wreedb/void-shepherd)
Title: Re: GNU Shepherd proposal
Post by: mrbrklyn on 10 June 2025, 05:04:06
I would be interested in seeing it. It would seem that Sheephard will be around for a very long time as it is core to GUIX.
Title: Re: GNU Shepherd proposal
Post by: konimex on 11 June 2025, 16:18:13
I'm actually interested to see if this works out, as this is the first time I actually see a working shepherd implementation outside of a Guix system, which is, frankly a PITA to decipher.
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?
Obviously, if we want to see this working, I believe PKGBUILDs should be made for shepherd, its rc/stage 1 files, and its service files so anyone interested can test it. Also, a crash course of directory structures (e.g. where enabled services go, user service directories, etc. etc.), service file structures, commands, etc. (As an example and a shameless plug of my past failed and successful experiment, finit (https://gitea.artixlinux.org/konimex/finit/src/branch/trunk/README) for the former and dinit (https://gitea.artixlinux.org/konimex/dinit/src/branch/master/README) for the latter) would be nice (though in my case for commands/controls just referring to a manpage would be enough if they're well-written).
In any case, good luck.
Title: Re: GNU Shepherd proposal
Post by: wreed on 12 June 2025, 01:42:20
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.
Title: Re: GNU Shepherd proposal
Post by: konimex on 12 June 2025, 03:50:26
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.
In runit they are invoked by /etc/runit/1, so you can probably symlink boot to it.
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.
Title: Re: GNU Shepherd proposal
Post by: wreed on 12 June 2025, 11:58:05
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:
/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
Title: Re: GNU Shepherd proposal
Post by: konimex on 12 June 2025, 15:06:00
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:
/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 (https://github.com/wreedb/void-shepherd/blob/bdbc7aea1bc0be6b386330a150d179286cc16a7d/init#L14), 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 (https://aur.archlinux.org/packages/shepherd))
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.
Title: Re: GNU Shepherd proposal
Post by: marzosh on 16 June 2025, 18:08:09
Hello! I'm also interested in this Shepherd approach for Artix Linux.
I tried reproducing the implementation following the tips from the messages above and the files from the repository, but got stuck right at the beginning of the boot process. The system complains that it can't find /boot and /tmp in the /etc/fstab file.
Note: *Artix doesn't have seedrng natively, so I took the liberty of compiling it and moving it to /usr/lib. *I changed the username to mine in the file: https://github.com/wreedb/void-shepherd/blob/main/system/etc/init.d/misc.scm#L7
Title: Re: GNU Shepherd proposal
Post by: mrbrklyn on 23 June 2025, 12:10:40
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:
/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 (https://github.com/wreedb/void-shepherd/blob/bdbc7aea1bc0be6b386330a150d179286cc16a7d/init#L14), 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 (https://aur.archlinux.org/packages/shepherd))
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.
So where you able to run shepherd an the init with the sockets in /run or not? Can't that just be moved to within /proc?