On 01/01/2015 11:33 PM, Isaac Dunham wrote:
> On Thu, Jan 01, 2015 at 03:52:17PM -0500, stephen Turner wrote:
>>>
>>>
>>> It doesn't have to be a script, but it does have to be written to match
>>> a specific set of rc scripts (the rc scripts are the shell part of
>>> the init system; there's OpenRC, the LFS init scripts, the Debian init
>>> scripts, the old RedHat init scripts, upstart and systemd implementions,
>>> Slackware init scripts, and probably several more I'm not aware of).
>>>
>>>
>>>
>> Got it, well im just looking for standard start/stop/restart services so
>> ill do a google later for a script or something i can utilize.
>
> If you have standard (sysv-ish/openrc) init scripts,
> # service sshd start
> is equal to:
> # /etc/init.d/sshd start
>
> In other words, a basic implementation that wouldn't work with
> upstart/systemd is as follows:
> #!/bin/sh
> "/etc/init.d/$1" "$2"
#!/bin/sh
cd /
exec env -i LANG="$LANG" PATH="$PATH" TERM="$TERM" "/etc/init.d/$1" "$2"
>>> No. It's toys/other/oneit.c (in the toybox tree).
>>>
>>> HTH,
>>> Isaac Dunham
>>>
>>>
>> Thanks, so I found the man for oneit but it only specifies opening a
>> terminal. what about processing an inittab? will it allow for runlevels or
>> adapt busybox style of no runlevel init?
>
> oneit runs a command.
> eg at the grub commandline:
>
> grub> root (hd0,5)
> grub> kernel /boot/bzImage root=/dev/sda6 init=/sbin/oneit -p sh
> grub> boot
>
> (hypothetical config with monolithic kernel built as bzImage, no
> inittmpfs/initramfs/initrd support, installed on second logical
> partition.)
>
> There is no inittab. There are no startup scripts, unless you write and
> run them manually.
Oneit does the song and dance to give the process it runs a controlling
tty (so you can run /bin/sh and ctrl-c works), when you exit it shuts
down (or reboots) cleanly instead of panicing the system, and it reaps
zombies so things reparented to init don't accumulate.
That's all it currently does. I'm pondering adding the ability for it to
open a pipe or fifo and write the exiting PIDs it accumulates to that so
another process can check them against a list of known launched daemons
and relaunch stuff that exited (or otherwise respond). I haven't figured
out how to do so safely yet (my choices are "block if the reader doesn't
read it", "drop data if the nonblocking write is ignored", or genericize
the netcat poll loop so this can fill toybuf[] with up to 4k of PIDs
(will they ever _not_ fit in an int? In that case we can do a ringbuffer
of 1024 pids before either discarding or blocking).
There was some discussion about this a few weeks ago between me and
dalias, which might be in the gmane list (or if dreamhost ever gets its
list constipation issue addressed)...
> If you want a (busybox-style) inittab and init scripts, enable "init"
> in toys/pending.
Um, yeah, that's in pending for a reason. Yesterday when I was going
through finally conerting all the strncpy() instances, I hit this:
next_command = strncpy(toybuf, command - hyphen, sizeof(toybuf));
next_command[sizeof(toybuf) - 1] = toybuf[sizeof(toybuf) - 1 ] = '\0';
command = next_command + hyphen;
strncpy returns its first argument, so next_command would _equal_
toybuf. I think they expected it to work like stpcpy() maybe? I haven't
gone on to see what they actually do with command or next command from
there, but i wouldn't trust it until I've had a chance to do a thorough
review.
> It hasn't been cleaned up, but I know it works.
I'll take your word for it.
> You will then want to create some files:
> /etc/inittab # chmod 0644
> /etc/init.d/rcS # chmod 0755
> /init # chmod 0755; hack because init needs /dev
>
> Traditionally, /etc/init.d/rcS ultimately does essentially:
> for SERVICE in /etc/rc${RUNLEVEL}.d/S*
> do "$SERVICE" start
> done
> for SERVICE in /etc/rc${RUNLEVEL}.d/K*
> do "$SERVICE" stop
> done
>
> and goes to the next runlevel.
Goes to the next runlevel? I thought the runlevels specified different
modes the system could run in (single user, server, desktop) and the
different directories had the various services appropriate to each.
> Of course, $RUNLEVEL is irrelevant in toybox.
If we're going to do svinit we should probably do it right, runlevels
and all.
That said, I've tabled the whole "init" question until I figure out what
I want lunchd to do, because sysinit can probably share infrastructure
with it. (I followed a macosx developer on twitter for a while and
that's how she labeled sandwich tweets as a pun on macos "launchd", and
I think it would make a good init name.)
(Also, I'd rather not do the busybox-style "have several shell
implementations and then a config optinon to specify which one /bin/sh
points to. If "init" is a command then "behave like svinit" might be a
config option under that. And it has to be called init because Linux has
a hardwired list of commands it tries to launch when you don't specify
init= on the command line.)
> And that method gives you a serial boot making it rather slow, and
> there are traditionally a dozen levels of indirection, making it
> even slower.
A serial boot is not necessarily slow.
http://landley.net/hg/aboriginal/file/1718/sources/root-filesystem/sbin/init.sh
http://www.linuxfromscratch.org/hints/downloads/files/bsd-init.txt
Also, it's quite possible to juggle arbitrary levels of parallelism in a
shell script. I implemented that towards the end of toybox's
scripts/make.sh to do parallel builds.
Now if you want to containerize daemons and relaunch exiting services,
you need the sort of thing upstart started towards. But if your services
are exiting something is _wrong_. (And if your sshd can crash why can't
your init crash? More to the point, there's a fine line between "crash"
and "remote exploit running arbitrary code"...)
> A minimalist example follows:
> ==/init==
> #!/bin/sh
> mount -t devtmpfs devtmpfs /dev
> exec /sbin/init
> ==EOF==
Speaking of which, remind me to write a patch so the kernel's
CONFIG_DEVTMPFS_MOUNT actually takes effect for initmpfs. It's just a
kernel internal "mkdir /dev" and "mount -t devfs devfs /dev", and it's
_already_ doing something like that for the console nonsense which could
be ripped _out_ if you devtmpfs instead).
Honestly, automounting devtmpfs init rootfs makes sense in a way that
automounting it into the root= filesystem does not. But I don't have
time to play kernel politics to try to attract anyone's attention, only
pushed the initmpfs patches because Cray wanted me to when I was working
there.
(I'd already have written it except I don't want to maintain it against
version skew _or_ get more of linux-kernel on me than strictly necessary.)
> ==/etc/inittab==
> ::sysinit:/etc/init.d/rcS
> tty1::respawn:/sbin/getty -l /bin/sh 38400 tty1
> tty2::respawn:/sbin/getty 38400 tty2
> tty3::respawn:/sbin/getty 38400 tty3
> ::shutdown:/bin/sync
> ::restart:/bin/sync
> tty1::shutdown:/bin/umount -a
> tty1::restart:/bin/umount -a
> ==EOF==
>
> ==rcS==
> #!/bin/sh
> PATH=/sbin:/bin
> mount -o remount,rw /dev/root /
> mount -t proc proc /proc
> mount -t sysfs sys /sys
> mkdir -p /dev/pts /dev/shm
> mount -t devpts devpts /dev/pts
> mount -t tmpfs devshm /dev/shm
> #to set modes of files in /dev:
> #echo "/sbin/mdev" >/proc/sys/kernel/hotplug
> #/sbin/mdev -s
> #/var/run and /var/log should be made writeable if they are not already:
> #mount -t tmpfs run /var/run
> #mount -t tmpfs log /var/log
> syslogd -S -D
> klogd
> find /sys -name modalias |xargs cat|xargs modprobe -abqs
> ==EOF==
One of the things I need to do when cleaning up svinit is write help
text, and that includes concisely but thoroughly explaining the darn
file format. This is, quite possibly, the hardest part.
> This will not do much for you, beyond making sure that drivers are loaded.
> You would need to configure networking.
> Also note that you get a login-free root shell on tty1.
I need to dust off mdev and redo that...
Working on it,
Rob
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
