Post by Isaac DunhamPost by stephen TurnerPost by Isaac DunhamIt 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
# /etc/init.d/sshd start
In other words, a basic implementation that wouldn't work with
#!/bin/sh
"/etc/init.d/$1" "$2"
#!/bin/sh
cd /
exec env -i LANG="$LANG" PATH="$PATH" TERM="$TERM" "/etc/init.d/$1" "$2"
Post by Isaac DunhamPost by stephen TurnerPost by Isaac DunhamNo. 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.
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)...
Post by Isaac DunhamIf 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.
Post by Isaac DunhamIt hasn't been cleaned up, but I know it works.
I'll take your word for it.
Post by Isaac Dunham/etc/inittab # chmod 0644
/etc/init.d/rcS # chmod 0755
/init # chmod 0755; hack because init needs /dev
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.
Post by Isaac DunhamOf 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.)
Post by Isaac DunhamAnd 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"...)
Post by Isaac Dunham==/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.)
Post by Isaac Dunham==/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
#echo "/sbin/mdev" >/proc/sys/kernel/hotplug
#/sbin/mdev -s
#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.
Post by Isaac DunhamThis 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