sinit - suckless init

dimigon · 2014-04-17 13:15:56

BTW, I added respawn in ubase - http://git.suckless.org/ubase/tree/respawn.c

jpgg · 2014-04-18 04:14:46

@dimigon The commit message for sinit 0.9 says "should be the final release". What does it mean?

dimigon · 2014-04-18 08:08:53

jpgg wrote:

@dimigon The commit message for sinit 0.9 says "should be the final release". What does it mean?

I do not expect that sinit requires any further development at this point.

dimigon · 2014-04-18 20:08:44

BTW, sinit now lives on http://suckless.org and the source code repo at http://git.suckless.org/sinit

Last edited by dimigon (2014-04-18 20:09:04)

jpgg · 2014-04-18 21:35:17

Nice! I have updated sinit-git and added sinit.

Mr Green · 2014-04-23 10:35:56

Have switched from busybox to sinit using servman fork. Can no longer shutdown or reboot. Need a way to halt machine and reboot. Can call rc {reboot/shutdown} as i added them into config.h. Functions get called but system does not power down or reboot (where this worked with busybox). Sinit does boot system even faster than busybox so do really want to use it. Any ideas on how to solve it?

dimigon · 2014-04-23 12:02:00

Mr Green wrote:

Have switched from busybox to sinit using servman fork. Can no longer shutdown or reboot. Need a way to halt machine and reboot. Can call rc {reboot/shutdown} as i added them into config.h. Functions get called but system does not power down or reboot (where this worked with busybox). Sinit does boot system even faster than busybox so do really want to use it. Any ideas on how to solve it?

Can you provide your rc scripts?

How do you initiate the reboot/shutdown sequence? Provide logs of what happens.

Which version of halt(8) do you use?

Assuming halt -r or halt -p is the last thing you do in the reboot/shutdown init scripts, you should probably
pass the -f flag if you are using anything other than the ubase halt implementation.

halt will try to signal init otherwise to initiate a clean reboot/shutdown sequence so I think you are stuck in a loop there or similar madness.

Last edited by dimigon (2014-04-23 12:14:15)

Mr Green · 2014-04-23 12:25:56

You will find my rc script here

https://github.com/mrgreen3/busyrc/blob/master/sbin/rc

Still got busybox in script, am trying to poweroff system from command

dimigon · 2014-04-23 12:30:17

Mr Green wrote:

You will find my rc script here
https://github.com/mrgreen3/busyrc/blob/master/sbin/rc
Still got busybox in script, am trying to poweroff system from command

shutdown/reboot are aliases for the halt program in busybox. You will need to use -f to bypass shutdown signalling busybox init (which is not there).

Similarly for reboot of course.

In particular, the original servman scripts use the ubase halt implementation (which defaults to -f) and has no init signalling implemented.

Last edited by dimigon (2014-04-23 12:37:31)

Mr Green · 2014-04-23 12:37:49

halt -f simply freezes system, halt -p does start rc shutdown then freezes. config,h has this in it which I think is correct.

/* See LICENSE file for copyright and license details. */

static char *const rcinitcmd[] = { "/sbin/rc", "init", NULL };
static char *const rcrebootcmd[] = { "/sbin/rc", "shutdown", NULL };
static char *const rcpoweroffcmd[] = { "/sbin/rc", "reboot", NULL };

Mr Green · 2014-04-23 12:46:50

Guess I need to load ubase-git from aur to get halt function back....

progandy · 2014-04-23 12:48:26

With busybox binaries it should go this way:
- call poweroff from shell -> signals sinit
Edit: sinit and busybox init use different signals, so this could be a problem, too. (busybox: USR1=halt, USR2=poweroff, TERM=reboot; sinit: USR1=poweroff, INT=reboot)
- signal sinit with e.g. killall -SIGUSR1 sinit
- sinit starts /sbin/rc shutdown
- /sbin/rc shutdown performs shutdown tasks.
- /sbin/rc shutdown runs "busybox poweroff -f" and termintaes

Last edited by progandy (2014-04-23 12:54:30)

dimigon · 2014-04-23 12:55:49

I added a manpage in the latest sinit git repo and there is a section on general recommendations. You should signal
sinit to initiate the reboot/poweroff sequence in the general case as opposed to running the script directly.

The reason for that is that killall5 kills all processes not in the current session (excluding init and kernel threads). If
any process in your session holds filesystem references, umount will fail.

If you signal it properly, then the init script will run in its own session (sinit does a setsid() before exec-ing).

I suspect the combination you are looking for in busybox halt is to use halt -fp for poweroff and halt -fr for reboot
or something similar.. I don't use busybox.

Last edited by dimigon (2014-04-23 13:00:55)

Mr Green · 2014-04-23 13:16:19

# killall -SIGUSR1 sinit

runs rc shutdown but function never completes, so busybox does not get called. Might switch back too busybox for init just for testing. (off to read manuals)

dimigon · 2014-04-23 14:35:45

Mr Green wrote:

# killall -SIGUSR1 sinit
runs rc shutdown but function never completes, so busybox does not get called. Might switch back too busybox for init just for testing. (off to read manuals)

Do the actual servman scripts work for you?

I am currently using some hacked CRUX initscripts - I put the code up here http://git.2f30.org/crux-initscripts/.
Note this is just a hack and should be done properly.

Mr Green · 2014-04-23 19:02:03

You beat me to it, had been looking at crux iso and init system they use. I had servman working with busybox then decided to fork code so I could basically get feel for init system. Changed to sinit which improved boot times but came across poweroff issue (hasten to add not sinits fault). Will take look at your scripts can easily run them under a vm....

dimigon · 2014-04-23 19:17:53

Mr Green wrote:

You beat me to it, had been looking at crux iso and init system they use. I had servman working with busybox then decided to fork code so I could basically get feel for init system. Changed to sinit which improved boot times but came across poweroff issue (hasten to add not sinits fault). Will take look at your scripts can easily run them under a vm....

Yeah, cool - diff them with the original ones to get a feel of what I changed, and you might want to polish the way they are organized so as to not conflict with existing tools in /sbin (namely I completely removed halt and poweroff/reboot from CRUX... I guess I could just use the existing one with the -f flag but I did not test it.)

Mr Green · 2014-04-23 19:32:15

Booting failed at /sbin/respawn (removed it for now) , not had chance to mess around with it much yet...much much much slower than servman. rc is doing much more work and it is good to check out how other systems work for inspiration.

rebootl · 2014-04-23 20:16:26

Had a quick look at http://git.2f30.org/crux-initscripts/tree/etc/rc.multi where respawn gets called.

/sbin/respawn /sbin/agetty -8 -s 38400 tty1 linux 
/sbin/respawn /sbin/agetty -8 -s 38400 tty2 linux 
/sbin/respawn /sbin/agetty -8 -s 38400 tty3 linux 
/sbin/respawn /sbin/agetty -8 -s 38400 tty4 linux

One problem might be that here the path to call respawn is: "/sbin/respawn"
But w/ the AUR ubase package respawn get's installed to /opt/ubase/.. or so.
While Arch has linked sbin to /usr/bin w/ that call it cannot find it in /opt/ubase/...

Another thing is that from what I can see here none of the calls is backgrounded (&).
Therefor when the path is correct and respawn is there, the first is executed but the following not. I think respawn continues to run it never exits.

Edit: @dimigon: As for respawn itself I had a look at the code and found it really amazing to figure out how this can be done crazy things...

As for my little dependency init, well, I'm still working on it and have it more or less working. But it turned out not so elegant as I wished for... The basic service structure is very similar to servman (inspired by it), just driven into extreme by making everything a service. The "rc" scripts ends up only being a handler for these services...

Last edited by rebootl (2014-04-23 20:40:53)

Mr Green · 2014-04-23 21:21:24

You can service most things but found hwclock did not work so well using them, also connman would connect some of the time. My script starts all and backgrounds them, maybe this approach only works for certain applications.

Rc script can be as simple or as complicated as you want, minirc for example loads daemons directly from script. Am sure we are reinventing the wheel but having fun all the same.

Once I figure out how to poweroff maybe then I wil on a real machine.

rebootl · 2014-04-23 22:08:52

Yeah, well for poweroff I notice that here /usr/bin/poweroff and /usr/bin/reboot are actually symlinks to /usr/bin/busybox. For the commands (busybox) poweroff -f or reboot -f this needs to be the case. But should be, if installed w/ pacman, I think. Though sysvinit, openRC or another init may overwrite this... (no offence).

When using halt from ubase you should probably use:

/opt/ubase/halt -r
/opt/ubase/halt -p

for reboot/poweroff.

The virtual machine might have an effect on this too, I don't know.

Edit: Above commands are for the final call only (!).

Am sure we are reinventing the wheel...

Yeah, it takes me most of the time to find new names for things that already exist .

My service files are just script parts. The same syntax as servman uses (start(), stop() and status()), the files and every function are completely optional (well you'll need something to tell that it should be started at boot and usually you'll want a file and functions) and contain an additional optional WAITFOR="... ..." variable for services to wait for. Anyways, currently the dependencies are not handled on a rock-solid base (FIFO's)...

Last edited by rebootl (2014-04-23 23:02:08)

jpgg · 2014-04-24 02:37:12

dimigon wrote:

The reason for that is that killall5 kills all processes not in the current session (excluding init and kernel threads). If
any process in your session holds filesystem references, umount will fail.
If you signal it properly, then the init script will run in its own session (sinit does a setsid() before exec-ing).

Is there an advantage of doing that instead of killing all processes (except init) with "kill -s TERM -1; kill -s KILL -1"?

Mr Green · 2014-04-24 06:00:37

Have sbase and ubase installed now so can test halt...before I go too far need to tidy my vm system up, as it has three different init systems loaded....

Now having problems booting, have this in config.h

/* See LICENSE file for copyright and license details. */

static char *const rcinitcmd[] = { "/sbin/rc", "init", NULL };
static char *const rcrebootcmd[] = { "/sbin/rc", "reboot", NULL };
static char *const rcpoweroffcmd[] = { "/sbin/rc", "shutdown", NULL };

Not sure if it is correct (after messing around with it!)

Last edited by Mr Green (2014-04-24 07:27:44)

dimigon · 2014-04-24 14:18:49

Mr Green wrote:

Have sbase and ubase installed now so can test halt...before I go too far need to tidy my vm system up, as it has three different init systems loaded....
Now having problems booting, have this in config.h
/* See LICENSE file for copyright and license details. */

static char *const rcinitcmd[] = { "/sbin/rc", "init", NULL };
static char *const rcrebootcmd[] = { "/sbin/rc", "reboot", NULL };
static char *const rcpoweroffcmd[] = { "/sbin/rc", "shutdown", NULL };
Not sure if it is correct (after messing around with it!)

Looks ok to me, it all depends on what you do in your scripts. But that should work as regards sinit.

dimigon · 2014-04-24 14:25:32

jpgg wrote:

dimigon wrote:
The reason for that is that killall5 kills all processes not in the current session (excluding init and kernel threads). If
any process in your session holds filesystem references, umount will fail.
If you signal it properly, then the init script will run in its own session (sinit does a setsid() before exec-ing).
Is there an advantage of doing that instead of killing all processes (except init) with "kill -s TERM -1; kill -s KILL -1"?

I think killall5 is not equivalent to kill with pid -1. killall5 will specifically not kill init, processes in its own session and kernel threads.
kill -s blabla -1 will kill all processes except the process itself and init (so processes in the same session other than the process itself will be killed).

It has been traditionally idiomatic to use killall5 in initscripts. If your shutdown/reboot procedure depends on a multitude of scripts running all in the same
session, you can expect that kill -s blabla -1 will incorrectly kill other scripts in your session that are needed. For a single script setup I doubt this
would be a problem.

Last edited by dimigon (2014-04-24 14:26:03)

Arch Linux

#51 2014-04-17 13:15:56

Re: sinit - suckless init

#52 2014-04-18 04:14:46

Re: sinit - suckless init

#53 2014-04-18 08:08:53

Re: sinit - suckless init

#54 2014-04-18 20:08:44

Re: sinit - suckless init

#55 2014-04-18 21:35:17

Re: sinit - suckless init

#56 2014-04-23 10:35:56

Re: sinit - suckless init

#57 2014-04-23 12:02:00

Re: sinit - suckless init

#58 2014-04-23 12:25:56

Re: sinit - suckless init

#59 2014-04-23 12:30:17

Re: sinit - suckless init

#60 2014-04-23 12:37:49

Re: sinit - suckless init

#61 2014-04-23 12:46:50

Re: sinit - suckless init

#62 2014-04-23 12:48:26

Re: sinit - suckless init

#63 2014-04-23 12:55:49

Re: sinit - suckless init

#64 2014-04-23 13:16:19

Re: sinit - suckless init

#65 2014-04-23 14:35:45

Re: sinit - suckless init

#66 2014-04-23 19:02:03

Re: sinit - suckless init

#67 2014-04-23 19:17:53

Re: sinit - suckless init

#68 2014-04-23 19:32:15

Re: sinit - suckless init

#69 2014-04-23 20:16:26

Re: sinit - suckless init

#70 2014-04-23 21:21:24

Re: sinit - suckless init

#71 2014-04-23 22:08:52

Re: sinit - suckless init

#72 2014-04-24 02:37:12

Re: sinit - suckless init

#73 2014-04-24 06:00:37

Re: sinit - suckless init

#74 2014-04-24 14:18:49

Re: sinit - suckless init

#75 2014-04-24 14:25:32

Re: sinit - suckless init

Board footer