Re: what init systems do you use ?
El lun., 13 may. 2019 a las 14:14, multiplexd () escribió: > It's been nearly two years since I set this up, so I don't recall all the > details, but I started out with a sysvinit Debian 9 system, and > reverse-engineered the boot sequence, which included a by-hand conversion > of all > the necessary /etc/init.d scripts into s6-rc service definitions. > > The particulars of the configuration I'm using are generally not portable > to > other machines though, > Is this init configuration available publicly? It seems like you did a bunch of work that could be useful for people trying to use s6 on debian, even when particulars should be polished.
Re: what init systems do you use ?
On Mon, 13 May 2019 20:13:29 +0100 multiplexd wrote: > All, > > On Fri, May 03, 2019 at 02:53:21AM +0200, Jeff wrote: > > what init systems do this list's subscribers use ? > > I saw Guillermo's reply up-thread, so I thought I'd add my own two > cents. My main workstation at present is a Debian 9 box booted with > s6 and s6-rc, with system setup and teardown (i.e. stages 1 and 3) > handled by some execline scripts heavily adapted from those generated > by s6-linux-init-maker 0.4.x.x. I use runit on all my Void Linux machines. Before using Void, I used sysvinit plus daemontools-encore. Whenever I had any problem with any daemon, or whenever I made my own daemon, I added it on to daemontools-encore, not to sysvinit's comments-actually-mean-something five function essay length init scripts. Experimentally I've initted with suckless-init plus s6. I even did Felker 16 line init + s6, which worked great if you didn't mind not having zombie-killing and signal based shutdown. I've also experimentally initted with Epoch and Systemd. I like the former and dislike the latter. SteveT
Re: what init systems do you use ?
All, On Fri, May 03, 2019 at 02:53:21AM +0200, Jeff wrote: > what init systems do this list's subscribers use ? I saw Guillermo's reply up-thread, so I thought I'd add my own two cents. My main workstation at present is a Debian 9 box booted with s6 and s6-rc, with system setup and teardown (i.e. stages 1 and 3) handled by some execline scripts heavily adapted from those generated by s6-linux-init-maker 0.4.x.x. It's been nearly two years since I set this up, so I don't recall all the details, but I started out with a sysvinit Debian 9 system, and reverse-engineered the boot sequence, which included a by-hand conversion of all the necessary /etc/init.d scripts into s6-rc service definitions. The boot process follows the general flow to be expected from a system using s6-svscan as PID 1. The stage 1 script sets up an initial service directory, spawns the script which starts stage 2 and then exec's into s6-svscan. Most of the runtime state configuration and management is then handled through s6-rc in stage 2. Stage 3 involves deactivating all the s6-rc managed services and then signalling the PID 1 s6-svscan, which execs into a script which kills the remaining processes, unmounts filesystems and then performs a halt, poweroff, or reboot as necessary. The particulars of the configuration I'm using are generally not portable to other machines though, as it was a proof-of-concept I came up with a year or two or go for a different system, which I then ported to my current workstation, which was set up in a very similar manner. I've also had to make it largely signal-compatible with sysvinit, as apt(8) sometimes attempts to reload the init configuration upon package changes. The signal used to request a configuration reload from sysvinit is SIGUSR1 if I recall correctly, however the default behaviour of the version of s6-linux-init-maker I was using at the time was to power off the machine upon receiving SIGUSR1 in PID 1, so I had to change the signal configuration for s6-svscan. That being said, it's been very stable and has largely stayed out my way, so it's been worth the initial setup effort in the long run. Cheers, --multiplexd.
Re: what init systems do you use ?
El jue., 2 may. 2019 a las 21:53, Jeff escribió:
>
> what init systems do this list's subscribers use ?
I have a Gentoo setup with no initramfs and one of the stable desktop
profiles (in the 'eselect profile' sense, which means GNU libc with
dynamic linking), that allows me to boot with an assortment of init
systems using the GRUB2 menu:
* sysvinit + OpenRC, using agetty from util-linux, to get a fully
functional system with one of the distribution's officially supported
configurations.
* runit + OpenRC, again using agetty from util-linux, to get a
somewhat restricted system for experimentation. Gentoo packages runit,
and OpenRC gets used because it is invoked by the supplied
/etc/runit/{1,3} files. Notable drawback: OpenRC's service scripts in
the sysinit and boot runlevels may launch unsupervised daemons that
runit doesn't know about.
* s6 + s6-rc, with version 0.4.x.x s6-linux-init-style scripts, again
using agetty from util-linux, to get an even more restricted system
for experimentation. OpenRC is inactive in this case, since s6-rc is
the service manager.
* nosh, with agetty replaced by a combination of the package's tool,
to get the same restricted system as for s6 + s6-rc. OpenRC is also
inactive in this case, since nosh contains a service manager (in the
skarnet.org documentation sense).
The "restricted system" scenarios would be less restricted, of course,
if I wrote, o grabbed and adapted from somewhere else, enough service
definitions for the selected init system, to match the sysvinit +
OpenRC configuration, but that means work of course.
G.
what init systems do you use ?
thanks for the interesting links. > https://www.reddit.com/r/linux/comments/2dx7k3/s6_skarnetorg_small_secure_supervision_software/cjxc1hj/?context=3 nice exchange of arguments. > Do not mistake causes for consequences. Things are not correct > because s6 does them; s6 does things because they are correct. well i thought it inherited that behaviour from daemontool's svscan. no i understand that this was a totally wrong assumption. :PP > Then you are free to use one of the many incorrect inits out there, > including sinit, Rich Felker's init, dumb-init, and others. You are > definitely not alone with your opinion. i wrote such an init myself which did a bit more than the ones you mention. it ran REALLY fast. the only thing that was slow was my usage of a customized (older) version of OpenRC (since i have written some own openrc scripts (adding perp "support" et al) and am too lazy to write my own scripts currently). > However, you sound interested in process supervision indeed. it's just a question of where to put the supervisor. > if you subscribe to that idea, then you > will understand why init must supervise at least 1 process. ok, i understand your arguments and of course there is something true about it. > Maybe you've never bricked a device because init didn't respawn > anything. well, i bricked my desktop when doing init experiments. but almost immediatly after hosing the system it comes into my mind what exactly went wrong and i fix this on reboot. i was forced to reboot from a rescue dvd only once so far. ;-) (when testing "ninit" which i don't recommend) and it involved only mounting the root fs on disc rw and fixing some symlinks in /sbin (init et al), so this was no real problem so long as one has console access. that's why i wrote (/sbin/)testinit that forks, execs into the real init to test in process #1 and sleeps a while in the child process after which it kill()s process #1 with given signals. this works usually very well and is safe to do. > I have. The "rather artificial and constructed argument" > happened to me in real life, and it was a significant inconvenience. oh no, i hope it was not a remote server ... :-/ always try things out on a box you have console access to or in a vm. BTW: what init systems do this list's subscribers use ? i use statically linked (musl) BusyBox init (and gettys) + mksh (https://www.mirbsd.org/mksh.htm) + s6 + OpenRC (v0.34.11, outdated) as default init system. i also ran perp but now run everything to be supervised under s6, started via a little setup shell script directly from /etc/inittab (most "one time tasks" are indeed directly run from the inittab file instead of a shell script).
