Re: [dev] Announcing sinit - the suckless init
On Sat, Feb 15, 2014 at 11:20:08PM +0100, Truls Becken wrote: > Rich Felker included a really minimalistic init in his recent blog post > "Broken by design: systemd" [1]. It was posted here to this thread by nsz. sinit was initially inspired by Rich Felker's init. > [1] http://ewontfix.com/14/
Re: [dev] Announcing sinit - the suckless init
Rich Felker included a really minimalistic init in his recent blog post "Broken by design: systemd" [1]. -Truls [1] http://ewontfix.com/14/
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 14, 2014 at 08:22:45PM +, Thorsten Glaser wrote: > Sylvain BERTRAND dixit: > > >Just to let you know, I have a little initramfs project. The > >init > >process is hardcoded directly on the linux syscalls. > > On Linux, syscall numbers, argument number, order and size, > etc. differ by architecture. Indeed, I have a *very* thin architecture abstraction in ulinux for that. I did only x86-64, but since it's very thin, I'm not that worried for new architecture addition. Usually, that bit is done by the libc. -- Sylvain
Re: [dev] Announcing sinit - the suckless init
Sylvain BERTRAND dixit: >Just to let you know, I have a little initramfs project. The init >process is hardcoded directly on the linux syscalls. On Linux, syscall numbers, argument number, order and size, etc. differ by architecture. bye, //mirabilos -- Ach, mach doch was du willst, du hast doch eh immer Recht! jupp ~/.etc/sig……… unfaßbar… Mit Eszett sogar, unfaßbar!
Re: [dev] Announcing sinit - the suckless init
Hi, Just to let you know, I have a little initramfs project. The init process is hardcoded directly on the linux syscalls. In the near futur, I hope to add the support to mount the root filesystem by label and by uuid. cheers, -- Sylvain
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 9:11 PM, sin wrote: > Fixed :) Nice, thank you.
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 08:53:16PM +0100, Krol, Willem van de wrote: > On Fri, Feb 7, 2014 at 2:02 PM, sin wrote: > > Yes, I realize signalfd() is Linux specific... aw well. > > Why did you choose signalfd() over sigwait()? The only advantage of > signalfd() seems to be poll()-ing or similar actions, which are not > used in sinit. Fixed :)
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 08:53:16PM +0100, Krol, Willem van de wrote: > On Fri, Feb 7, 2014 at 2:02 PM, sin wrote: > > Yes, I realize signalfd() is Linux specific... aw well. > > Why did you choose signalfd() over sigwait()? The only advantage of > signalfd() seems to be poll()-ing or similar actions, which are not > used in sinit. It is a left-over from when I was multiplexing the file descriptors of the FIFO and the signal dispatching. I will fix it, thanks for pointing out.
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 7, 2014 at 2:02 PM, sin wrote: > Yes, I realize signalfd() is Linux specific... aw well. Why did you choose signalfd() over sigwait()? The only advantage of signalfd() seems to be poll()-ing or similar actions, which are not used in sinit. Willem
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 03:51:40PM +, sin wrote: > On Mon, Feb 10, 2014 at 02:44:11PM +0100, Eckehard Berns wrote: > > On Mon, Feb 10, 2014 at 12:31:59PM +, sin wrote: > > > I just pushed a simple implementation of getty[1] to ubase. Would > > > be nice to see if that works ok with your setup (and maybe get rid of > > > fgetty ;-)). > > > > I could only test it briefly. At first it seemed to work as expected. > > Then I realized that you cheated your way around asking for the > > username. On Slackware /bin/login times out after 60 seconds which will > > clutter the vt after a couple of minutes with timeout messages and login > > prompts. So it seems that getty should ask for the username first even > > if login could do it as well. > > Fixed in upstream ubase. It should work ok now. Works like a charm. Just replaced fgetty :) -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 02:44:11PM +0100, Eckehard Berns wrote: > On Mon, Feb 10, 2014 at 12:31:59PM +, sin wrote: > > I just pushed a simple implementation of getty[1] to ubase. Would > > be nice to see if that works ok with your setup (and maybe get rid of > > fgetty ;-)). > > I didn't dare to ask if there was a suckless getty :) Thanks for that! > > I could only test it briefly. At first it seemed to work as expected. > Then I realized that you cheated your way around asking for the > username. On Slackware /bin/login times out after 60 seconds which will > clutter the vt after a couple of minutes with timeout messages and login > prompts. So it seems that getty should ask for the username first even > if login could do it as well. Fixed in upstream ubase. It should work ok now.
Re: [dev] Announcing sinit - the suckless init
On Mon, Feb 10, 2014 at 12:31:59PM +, sin wrote: > I just pushed a simple implementation of getty[1] to ubase. Would > be nice to see if that works ok with your setup (and maybe get rid of > fgetty ;-)). I didn't dare to ask if there was a suckless getty :) Thanks for that! I could only test it briefly. At first it seemed to work as expected. Then I realized that you cheated your way around asking for the username. On Slackware /bin/login times out after 60 seconds which will clutter the vt after a couple of minutes with timeout messages and login prompts. So it seems that getty should ask for the username first even if login could do it as well. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Sat, Feb 08, 2014 at 11:58:47PM +0100, Eckehard Berns wrote: > On Fri, Feb 07, 2014 at 09:36:01PM +, sin wrote: > > On Fri, Feb 07, 2014 at 09:56:17PM +0100, Eckehard Berns wrote: > > > I tested v0.3 and besides some glitches due to my system everything > > > worked fine. I'm using fgetty (yeah, freeing a couple more kb might > > > not be worth using it, but I tried it some time ago and kept it) and > > > it complains about file descriptor 3 when I try to log in. Aparently > > > (haven't checked the fgetty code) it uses file descriptor 3 for internal > > > communication of some sort and that would be sinit's sigfd. I added > > > a line to spawn() to close sigfd in the first child (if sigfd >= 0) > > > and I could log in again. > > > > I use SFD_CLOEXEC now - should work. > > Just had a chance to test v0.4-4-gebccd1b and everything works > beautifully. Hi there, I just pushed a simple implementation of getty[1] to ubase. Would be nice to see if that works ok with your setup (and maybe get rid of fgetty ;-)). [1] http://git.2f30.org/ubase/tree/getty.c
Re: [dev] Announcing sinit - the suckless init
* sin [2014-02-07 21:26:11 +]: > On Fri, Feb 07, 2014 at 05:26:54PM +0100, Szabolcs Nagy wrote: > > note that strake got that init code is from Rich Felker > > and there is more to it than that code.. (you may find > > related discussions on the musl mailing list archive, > > he also planned to write about reliable init systems on > > ewontfix.com so you may want to check that out as well) > > > > > [2] https://github.com/strake/init > > > > compare to > > https://gist.github.com/rofl0r/6168719 > > nsz, thanks for clarifying! I will give proper credit > to Rich Felker and check out the discussions. and here is the promised writing http://ewontfix.com/14/ (see "So how should init be done right?" section)
Re: [dev] Announcing sinit - the suckless init
On Sun, Feb 09, 2014 at 01:36:21PM -0500, Bryan Bennett wrote: > Well, damnit. Gmail's web interface strikes again... > > As I was saying... > > I've not had the chance to try this out myself, but I'm curious what > this provides > (or doesn't provide, given the collective mindsets on this mailinglist, myself > included) that something like minirc[1] does or doesn't do. Thanks for pointing out minirc, but sinit is just an implementation of the init(8) program, it is not tied to any particular set of init scripts like minirc. Without hacking minirc, sinit would not work with it as I do not want to support an inittab file. sinit is entirely configured via config.h. minirc has been tested with busybox init. I am trying hard to get rid of busybox from my systems and this is my attempt at implementing a simple init system that does the bare minimum needed. Everything else comes either as a separate tool or as part of the init scripts (like sanitizing PATH etc.)
Re: [dev] Announcing sinit - the suckless init
Well, damnit. Gmail's web interface strikes again... As I was saying... I've not had the chance to try this out myself, but I'm curious what this provides (or doesn't provide, given the collective mindsets on this mailinglist, myself included) that something like minirc[1] does or doesn't do. In particular, Minirc is a POSIX shell script that supports multiple device backends (mdev, udev from systemd, & eudev out of the box - more if we want to add them) and does so in one of the simplest frameworks I've seen. Want a new service? If it's just one command started on boot (sshd, for instance) just add it to the DAEMONS array. If it's more than that - just implement a switch/ case statement and fall back to the default implemention if it's not what you expect. The source is simple to grok and it implements daemons (though whether or not that's good is up to discussion). Is the difference here one of implementation (C vs Shell)? Or just intention? I've seen a lot of tiny init's recently and I'm trying to figure out where the middle ground is, while discarding behemoths like systemd. 1: http://github.com/hut/minirc
Re: [dev] Announcing sinit - the suckless init
I've not had the chance to try this out myself, but I'm curious what this provides (or doesn't provide, given the collective mindsets on this mailinglist, myself included) that something like minirc[1] does or doesn't do. In particular, Minirc is a
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 09:36:01PM +, sin wrote: > On Fri, Feb 07, 2014 at 09:56:17PM +0100, Eckehard Berns wrote: > > I tested v0.3 and besides some glitches due to my system everything > > worked fine. I'm using fgetty (yeah, freeing a couple more kb might > > not be worth using it, but I tried it some time ago and kept it) and > > it complains about file descriptor 3 when I try to log in. Aparently > > (haven't checked the fgetty code) it uses file descriptor 3 for internal > > communication of some sort and that would be sinit's sigfd. I added > > a line to spawn() to close sigfd in the first child (if sigfd >= 0) > > and I could log in again. > > I use SFD_CLOEXEC now - should work. Just had a chance to test v0.4-4-gebccd1b and everything works beautifully. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Sat, Feb 08, 2014 at 09:27:36AM +0100, Truls Becken wrote: > Hi, > > Wrapping the argument to spawn in Arg union is useless now. > Probably a leftover from the design with FIFO. Yeah, indeed. Will remove.
Re: [dev] Announcing sinit - the suckless init
Hi, Wrapping the argument to spawn in Arg union is useless now. Probably a leftover from the design with FIFO. -Truls
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 09:00:34PM +, sin wrote: > On Fri, Feb 07, 2014 at 09:56:17PM +0100, Eckehard Berns wrote: > > And since sinit uses Linux specific code anyway you might consider > > calling reboot(0) to tell the kernel to send SIGINT to pid 1 on > > ctrl-alt-del. > > I implemented ctrlaltdel(8) in ubase and I call it in my init scripts > to set the ctrl-alt-del behaviour. Oh, I see. That's nice. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 09:56:17PM +0100, Eckehard Berns wrote: > I tested v0.3 and besides some glitches due to my system everything > worked fine. I'm using fgetty (yeah, freeing a couple more kb might > not be worth using it, but I tried it some time ago and kept it) and > it complains about file descriptor 3 when I try to log in. Aparently > (haven't checked the fgetty code) it uses file descriptor 3 for internal > communication of some sort and that would be sinit's sigfd. I added > a line to spawn() to close sigfd in the first child (if sigfd >= 0) > and I could log in again. I use SFD_CLOEXEC now - should work. > Speaking of children, I think you could drop the double fork in spawn > now, since pid 1 already waits for children. Done.
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 05:26:54PM +0100, Szabolcs Nagy wrote: > * sin [2014-02-06 12:32:59 +]: > > As part of experimenting with a toy distro I wanted to get rid of > > busybox's init, so I hacked together sinit[1]. sinit is based on Strake's > > init[2]. > > note that strake got that init code is from Rich Felker > and there is more to it than that code.. (you may find > related discussions on the musl mailing list archive, > he also planned to write about reliable init systems on > ewontfix.com so you may want to check that out as well) > > > [2] https://github.com/strake/init > > compare to > https://gist.github.com/rofl0r/6168719 nsz, thanks for clarifying! I will give proper credit to Rich Felker and check out the discussions.
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 09:56:17PM +0100, Eckehard Berns wrote: > On Fri, Feb 07, 2014 at 04:24:03PM +, sin wrote: > > Well, I completely removed the FIFO code :) > > That simplifies things :) > > I tested v0.3 and besides some glitches due to my system everything > worked fine. I'm using fgetty (yeah, freeing a couple more kb might > not be worth using it, but I tried it some time ago and kept it) and > it complains about file descriptor 3 when I try to log in. Aparently > (haven't checked the fgetty code) it uses file descriptor 3 for internal > communication of some sort and that would be sinit's sigfd. I added > a line to spawn() to close sigfd in the first child (if sigfd >= 0) > and I could log in again. Aha, I see. I will try testing with fgetty as well. > Speaking of children, I think you could drop the double fork in spawn > now, since pid 1 already waits for children. Makes sense. > And since sinit uses Linux specific code anyway you might consider > calling reboot(0) to tell the kernel to send SIGINT to pid 1 on > ctrl-alt-del. I implemented ctrlaltdel(8) in ubase and I call it in my init scripts to set the ctrl-alt-del behaviour.
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 04:24:03PM +, sin wrote: > Well, I completely removed the FIFO code :) That simplifies things :) I tested v0.3 and besides some glitches due to my system everything worked fine. I'm using fgetty (yeah, freeing a couple more kb might not be worth using it, but I tried it some time ago and kept it) and it complains about file descriptor 3 when I try to log in. Aparently (haven't checked the fgetty code) it uses file descriptor 3 for internal communication of some sort and that would be sinit's sigfd. I added a line to spawn() to close sigfd in the first child (if sigfd >= 0) and I could log in again. Speaking of children, I think you could drop the double fork in spawn now, since pid 1 already waits for children. And since sinit uses Linux specific code anyway you might consider calling reboot(0) to tell the kernel to send SIGINT to pid 1 on ctrl-alt-del. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
* sin [2014-02-06 12:32:59 +]: > As part of experimenting with a toy distro I wanted to get rid of > busybox's init, so I hacked together sinit[1]. sinit is based on Strake's > init[2]. note that strake got that init code is from Rich Felker and there is more to it than that code.. (you may find related discussions on the musl mailing list archive, he also planned to write about reliable init systems on ewontfix.com so you may want to check that out as well) > [2] https://github.com/strake/init compare to https://gist.github.com/rofl0r/6168719
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 01:42:36PM +0100, Eckehard Berns wrote: > On Fri, Feb 07, 2014 at 12:03:03PM +, sin wrote: > > I've fixed the issues you mentioned except the case when rootfs is mounted > > as ro. > > > > How would you tackle that? > > I thought about this a bit. If the fifo is present when booting the > ro root fs everything should be fine. You wouldn't be able to unlink > fifopath or create it, but since it's already there the call to open() > should succeed. You'd have to ignore errors for unlink() and mkfifo() > and only check open() for errors. I can't test this at the moment, but I > think this might work. Well, I completely removed the FIFO code :)
Re: [dev] Announcing sinit - the suckless init
On 02/07/2014 02:02 PM, sin wrote: Yes, I realize signalfd() is Linux specific... aw well. Then again, you wrote sinit with stali in mind.
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 01:42:36PM +0100, Eckehard Berns wrote: > On Fri, Feb 07, 2014 at 12:03:03PM +, sin wrote: > > I've fixed the issues you mentioned except the case when rootfs is mounted > > as ro. > > > > How would you tackle that? > > I thought about this a bit. If the fifo is present when booting the > ro root fs everything should be fine. You wouldn't be able to unlink > fifopath or create it, but since it's already there the call to open() > should succeed. You'd have to ignore errors for unlink() and mkfifo() > and only check open() for errors. I can't test this at the moment, but I > think this might work. Hi, I refactored the code and this is what I have now: http://git.2f30.org/sinit/commit/?id=8194f460daaa9343ce9863838b14132d0ad8037c >From the commit message: "We no longer have two processes, one for reaping children and another for handling the FIFO. Use signalfd() to multiplex signal handling and reading from the FIFO. This setup will also allow us to capture ctrl-alt-del and to work with a read-only rootfs. To create the FIFO, we send a SIGHUP signal to init from our init scripts." Yes, I realize signalfd() is Linux specific... aw well. Cheers, sin
Re: [dev] Announcing sinit - the suckless init
On Fri, Feb 07, 2014 at 12:03:03PM +, sin wrote: > I've fixed the issues you mentioned except the case when rootfs is mounted > as ro. > > How would you tackle that? I thought about this a bit. If the fifo is present when booting the ro root fs everything should be fine. You wouldn't be able to unlink fifopath or create it, but since it's already there the call to open() should succeed. You'd have to ignore errors for unlink() and mkfifo() and only check open() for errors. I can't test this at the moment, but I think this might work. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 11:40:22PM +0100, Eckehard Berns wrote: > On Thu, Feb 06, 2014 at 09:54:44PM +, sin wrote: > > Hm yes, you are right, the FIFO code never reaps children. We could > > probably use the double fork trick + killing the parent to force it to > > be reaped by the original process (the parent of the FIFO code). > > Double forking would take care of the spawned process. But you'd still be > forced to boot with the file system mounted read-write. I don't know if > that's the way to go. I think Arch wants you to boot with a read-writable > root fs nowadays, but I don't know what the benefit should be. Even more > so since you need to remount it read-only during system initialisation > anyway before checking it. I've fixed the issues you mentioned except the case when rootfs is mounted as ro. How would you tackle that? I am considering setting up a SIGHUP handler in init and then sending that signal at the end of the boot process when we are basically ready. What do you think? Cheers, sin
Re: [dev] Announcing sinit - the suckless init
Eckehard Berns dixit: >I actually use ctrl-alt-del and alt-up from time to time :) But I could >live without it. Hmm, I actually forgot. Do the BSDs handle ctrl-alt-del >in any way on x86? Yes. Not just on x86. It sends SIGUSR1 to pid 1. bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 09:41:09PM +, Thorsten Glaser wrote: > Hm, isn’t Ctrl-Alt-Backspace+Ctrl-Alt-Del (when not using xdm) > or Ctrl-Alt-F1+Ctrl-Alt-Del the normal way to shutdown a system? I actually use ctrl-alt-del and alt-up from time to time :) But I could live without it. Hmm, I actually forgot. Do the BSDs handle ctrl-alt-del in any way on x86? -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 09:54:44PM +, sin wrote: > Hm yes, you are right, the FIFO code never reaps children. We could > probably use the double fork trick + killing the parent to force it to > be reaped by the original process (the parent of the FIFO code). Double forking would take care of the spawned process. But you'd still be forced to boot with the file system mounted read-write. I don't know if that's the way to go. I think Arch wants you to boot with a read-writable root fs nowadays, but I don't know what the benefit should be. Even more so since you need to remount it read-only during system initialisation anyway before checking it. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 09:03:38PM +0100, Hadrian Węgrzynowski wrote: > Dnia 2014-02-06, o godz. 12:32:59 > Hey. > > Did you saw qinit[1] from David Galos? Yes, it does a bit more than what I'd expect from init. It is also a bit racy, I have a patched version somewhere that sort of works.
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 09:36:23PM +0100, Eckehard Berns wrote: > On Thu, Feb 06, 2014 at 12:32:59PM +, sin wrote: > > As part of experimenting with a toy distro I wanted to get rid of > > busybox's init, so I hacked together sinit[1]. sinit is based on Strake's > > init[2]. > > [...] > > Let me know what you guys think, I am looking forward to use this with > > sta.li. > > I now had time to test sinit. I first had trouble getting the FIFO > to work. When booting with the root fs mounted read-only, the child > dealing with the FIFO would segfault. When booting with my root fs > mounted read-write my rcinitcmd would become a zombe since the FIFO code > never reaps children. Thanks for testing! I think the segfault could have been caused because there was no error checking for open(2). I added that in later. Hm yes, you are right, the FIFO code never reaps children. We could probably use the double fork trick + killing the parent to force it to be reaped by the original process (the parent of the FIFO code). > So I changed spawn() to wait for its child. Now I can mount my root fs > read-write in my rcinitcmd or even setup a tmpfs, and my rcinitcmd will > have its exit status checked and not become a zombie. This means though > that you can't use the FIFO until the rcinitcmd exited (which means > you might want to chane your rc.svc to background the agetty loop). Yeah something did not feel right with having the rc script block. I presume if we use the aforementioned double fork trick, we'll be able to continue even if rc.svc doesn't exit (I may be hallucinating right now, I will check tomorrow if what I am saying makes sense). > Also, would it be worth it to deal with x86 Linux's ctrl-alt-del? It would > pull in OS specific code, and maybe people don't care for ctrl-alt-del > on the console, since everybody lives in X anyway. Hm, not sure. What you guys think?
Re: [dev] Announcing sinit - the suckless init
Eckehard Berns dixit: >Also, would it be worth it to deal with x86 Linux's ctrl-alt-del? It would >pull in OS specific code, and maybe people don't care for ctrl-alt-del >on the console, since everybody lives in X anyway. Hm, isn’t Ctrl-Alt-Backspace+Ctrl-Alt-Del (when not using xdm) or Ctrl-Alt-F1+Ctrl-Alt-Del the normal way to shutdown a system? bye, //mirabilos -- Ach, mach doch was du willst, du hast doch eh immer Recht! jupp ~/.etc/sig……… unfaßbar… Mit Eszett sogar, unfaßbar!
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 12:32:59PM +, sin wrote: > As part of experimenting with a toy distro I wanted to get rid of > busybox's init, so I hacked together sinit[1]. sinit is based on Strake's > init[2]. > [...] > Let me know what you guys think, I am looking forward to use this with sta.li. I now had time to test sinit. I first had trouble getting the FIFO to work. When booting with the root fs mounted read-only, the child dealing with the FIFO would segfault. When booting with my root fs mounted read-write my rcinitcmd would become a zombe since the FIFO code never reaps children. So I changed spawn() to wait for its child. Now I can mount my root fs read-write in my rcinitcmd or even setup a tmpfs, and my rcinitcmd will have its exit status checked and not become a zombie. This means though that you can't use the FIFO until the rcinitcmd exited (which means you might want to chane your rc.svc to background the agetty loop). Also, would it be worth it to deal with x86 Linux's ctrl-alt-del? It would pull in OS specific code, and maybe people don't care for ctrl-alt-del on the console, since everybody lives in X anyway. -- Eckehard Berns
Re: [dev] Announcing sinit - the suckless init
Dnia 2014-02-06, o godz. 12:32:59 sin napisał(a): > Hi all, > > As part of experimenting with a toy distro I wanted to get rid of > busybox's init, so I hacked together sinit[1]. sinit is based on > Strake's init[2]. > > It is currently controlled via a FIFO. It supports only two commands > (reboot and poweroff). > > It follows the classic style of config.def.h and it should work with > any init scripts. I've been testing it with my init scripts[3]. > > Let me know what you guys think, I am looking forward to use this > with sta.li. > > Thanks, > sin > > [1] http://git.2f30.org/sinit > [2] https://github.com/strake/init > [3] http://git.2f30.org/fs/ > Hey. Did you saw qinit[1] from David Galos? It seems that some of ideas overlap and some features could be reused, like "reload" on fly. [1] http://galos.no-ip.org/qinit
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 07:54:17PM +0100, YpN wrote: > > Let me know what you guys think, I am looking forward to use this with > > sta.li. > > I will probably try it this month. And you should add it on > the "rocks" page. For now, I don't have any advices, but it > could be good to "support" daemons. daemons are handled separately and outside of init. In my setup I have some simple scripts in /bin/rc.d. In the future I am planning to use svc[1]. [1] http://git.r-36.net/svc/
Re: [dev] Announcing sinit - the suckless init
Good evening, sin wrote: > As part of experimenting with a toy distro I wanted to get rid of > busybox's init, so I hacked together sinit[1]. sinit is based on Strake's > init[2]. This is a wonderful idea. Few months ago, we talked about a "suckless" init. I am happy to see something new (and not related to busybox). > It is currently controlled via a FIFO. It supports only two commands (reboot > and poweroff). I like FIFO so much, good job! > Let me know what you guys think, I am looking forward to use this with sta.li. I will probably try it this month. And you should add it on the "rocks" page. For now, I don't have any advices, but it could be good to "support" daemons. Regards Y.
Re: [dev] Announcing sinit - the suckless init
On Thu, Feb 06, 2014 at 02:46:43PM +0100, Eckehard Berns wrote: > > As part of experimenting with a toy distro I wanted to get rid of > > busybox's init, so I hacked together sinit[1]. sinit is based on Strake's > > init[2]. > > > > It is currently controlled via a FIFO. It supports only two commands > > (reboot > > and poweroff). > > Why are those included? sinit does nothing but reaping zombies. Using > it to spawn shutdown scripts seems kinda wrong to me. Why not call the > shutdown scripts directly to poweroff or reboot the system? Yes, you can call the shutdown script directly. I was floating between this decision myself. I might just as well remove support for that.
Re: [dev] Announcing sinit - the suckless init
> As part of experimenting with a toy distro I wanted to get rid of > busybox's init, so I hacked together sinit[1]. sinit is based on Strake's > init[2]. > > It is currently controlled via a FIFO. It supports only two commands (reboot > and poweroff). Why are those included? sinit does nothing but reaping zombies. Using it to spawn shutdown scripts seems kinda wrong to me. Why not call the shutdown scripts directly to poweroff or reboot the system? -- Eckehard Berns
