Discussion:
service
(too old to reply)
stephen Turner
2015-01-01 14:35:31 UTC
Permalink
while doing some searches on scripting i was reminded about "service" and
noticed it wasn't in toybox. Is this a oversight or not in intended
feature/possible post 1.0.

thanks
stephen
Rob Landley
2015-01-01 17:02:14 UTC
Permalink
Post by stephen Turner
while doing some searches on scripting i was reminded about "service"
and noticed it wasn't in toybox. Is this a oversight or not in intended
feature/possible post 1.0.
$ man service

NAME
service - run a System V init script

...
DESCRIPTION
service runs a System V init script or upstart job in as predictable
environment as possible, removing most environment variables and with
current working directory set to /.

You mean that?

Rob
stephen Turner
2015-01-01 18:03:14 UTC
Permalink
Post by Rob Landley
Post by stephen Turner
while doing some searches on scripting i was reminded about "service"
and noticed it wasn't in toybox. Is this a oversight or not in intended
feature/possible post 1.0.
$ man service
NAME
service - run a System V init script
...
DESCRIPTION
service runs a System V init script or upstart job in as predictable
environment as possible, removing most environment variables and
with
Post by Rob Landley
current working directory set to /.
You mean that?
Rob
Yea that would be it. I havent grabbed the latest toybox so I wouldnt know
if its already in it but a quich check of the website didnt have it listed.
If its not a planned feature thats fine just wanted to know what the plan
was for it.

Thanks
Stephen
Rob Landley
2015-01-02 03:27:07 UTC
Permalink
Post by Rob Landley
Post by Rob Landley
Post by stephen Turner
while doing some searches on scripting i was reminded about "service"
and noticed it wasn't in toybox. Is this a oversight or not in intended
feature/possible post 1.0.
$ man service
NAME
service - run a System V init script
...
DESCRIPTION
service runs a System V init script or upstart job in as
predictable
Post by Rob Landley
environment as possible, removing most environment variables
and with
Post by Rob Landley
current working directory set to /.
You mean that?
Rob
Yea that would be it. I havent grabbed the latest toybox so I wouldnt
know if its already in it but a quich check of the website didnt have it
listed. If its not a planned feature thats fine just wanted to know what
the plan was for it.
Didn't have a plan. First I've noticed it, really. I take it that's a
thing you need? (Is there any sort of standard for it? It sounds like
it's basically a shell script built around env -i...)

Ah, the ubuntu version _is_ a shell script built around env -i, the
heart of which is:

cd /
exec env -i LANG="$LANG" PATH="$PATH" TERM="$TERM" \
"$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}

Rob
stephen Turner
2015-01-02 03:34:51 UTC
Permalink
Post by Rob Landley
Post by Rob Landley
Post by Rob Landley
Post by stephen Turner
while doing some searches on scripting i was reminded about "service"
and noticed it wasn't in toybox. Is this a oversight or not in intended
feature/possible post 1.0.
$ man service
NAME
service - run a System V init script
...
DESCRIPTION
service runs a System V init script or upstart job in as
predictable
Post by Rob Landley
environment as possible, removing most environment variables
and with
Post by Rob Landley
current working directory set to /.
You mean that?
Rob
Yea that would be it. I havent grabbed the latest toybox so I wouldnt
know if its already in it but a quich check of the website didnt have it
listed. If its not a planned feature thats fine just wanted to know what
the plan was for it.
Didn't have a plan. First I've noticed it, really. I take it that's a
thing you need? (Is there any sort of standard for it? It sounds like
it's basically a shell script built around env -i...)
Ah, the ubuntu version _is_ a shell script built around env -i, the
cd /
exec env -i LANG="$LANG" PATH="$PATH" TERM="$TERM" \
"$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
Rob
Yea, this is probobly one of those things best left to the individual to
supply im guessing. Short of people running a full system I dont imagine
there will be as much need for starting and stoping daemons.

Addmittently I asked before thinking with this one.
Isaac Dunham
2015-01-01 20:37:12 UTC
Permalink
service(8) is part of the rc scripts, of which there are more variants
than there are of init(8).
so service is a script? ok, i thought it was a program and thought surely
we would want it in toybox if it was. Come to think of it i do recall
reading about writing your own service script when i was checking out
embedded stuff.
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).
It makes little sense to include it in toybox when the only init we have
is oneit; even when init gets out of pending, implementing service in
toybox would be hard-coding a requirement about how the rc scripts work.
We certainly couldn't implement the rc scripts in toybox, since
they are scripts.
A google search turns up zilch on oneit. Is there a website for it?
No. It's toys/other/oneit.c (in the toybox tree).

HTH,
Isaac Dunham
stephen Turner
2015-01-01 20:52:17 UTC
Permalink
Post by Isaac Dunham
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.
Post by Isaac Dunham
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?
Isaac Dunham
2015-01-02 05:33:12 UTC
Permalink
Post by stephen Turner
Post by Isaac Dunham
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"
Post by stephen Turner
Post by Isaac Dunham
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.


If you want a (busybox-style) inittab and init scripts, enable "init"
in toys/pending. It hasn't been cleaned up, but I know it works.
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.
Of course, $RUNLEVEL is irrelevant in toybox.
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 minimalist example follows:
==/init==
#!/bin/sh
mount -t devtmpfs devtmpfs /dev
exec /sbin/init
==EOF==

==/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==

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.

HTH,
Isaac Dunham
Rob Landley
2015-01-02 21:57:04 UTC
Permalink
Post by Isaac Dunham
Post by stephen Turner
Post by Isaac Dunham
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
# /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 Dunham
Post by stephen Turner
Post by Isaac Dunham
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.
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 Dunham
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.
Post by Isaac Dunham
It 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 Dunham
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.)
Post by Isaac Dunham
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"...)
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 Dunham
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
stephen Turner
2015-01-02 22:37:17 UTC
Permalink
Post by Rob Landley
/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.
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.)
So while reading up on init, i found this bsd init which doesnt have run
levels https://www.freebsd.org/doc/en/articles/linux-users/startup.html
and i became curious, whats the big deal with run levels anyways? so i see
we have halt, reboot, and what looks like full normal 5. At first i always
assumed the other run levels were like safe mode in windows but after
digging and building i find there isn't any undamaged os repository (image)
for such a safe run level. So i guess my question is, who cares about run
levels if your always going to run 5 reboot 6 and halt 0 ? you can just
have those and be done with it, or is there a usefulness to run levels?
Personally i dont use them. And i suppose there could be a use for booting
your computer with reduced services but honestly why?

(raises hands and prays please don't start flame war)
stephen Turner
2015-01-01 20:39:04 UTC
Permalink
forgot to copy list again.
service(8) is part of the rc scripts, of which there are more variants
than there are of init(8).
so service is a script? ok, i thought it was a program and thought surely
we would want it in toybox if it was. Come to think of it i do recall
reading about writing your own service script when i was checking out
embedded stuff.
It makes little sense to include it in toybox when the only init we have
is oneit; even when init gets out of pending, implementing service in
toybox would be hard-coding a requirement about how the rc scripts work.
We certainly couldn't implement the rc scripts in toybox, since
they are scripts.
A google search turns up zilch on oneit. Is there a website for it?
In case you're wondering: the number in parentheses is the man section;
(1)=user commands, (2)=syscalls, (3)=functions/libraries, (8)=system
administration tools.
HTH,
Isaac Dunham
David Seikel
2015-01-02 03:20:11 UTC
Permalink
Post by stephen Turner
while doing some searches on scripting i was reminded about
"service" and noticed it wasn't in toybox. Is this a oversight or
not in intended feature/possible post 1.0.
service(8) is part of the rc scripts, of which there are more variants
than there are of init(8).
It makes little sense to include it in toybox when the only init we
have is oneit; even when init gets out of pending, implementing
service in toybox would be hard-coding a requirement about how the rc
scripts work. We certainly couldn't implement the rc scripts in
toybox, since they are scripts.
That's not entirely true. Many years ago I wrote an implementation of
runlevel/init.d/SYS V init applets for busybox, aiming for LSB
compliance. It included the ability for the actual "scripts"
themselves to be written in any language, and included several ones
written in C as busybox applets. These init "scripts" would just be
symlinks to busybox. This is in fact compliant with the LSB
specification.

If I remember correctly, it includes most of the good stuff systemd
claims, fast boot if all/most of the "scripts" are written in C,
dependency tracking, parallel "script" running, etc.

Rob hasn't decided yet how to tackle this sort of thing, other than his
oneit toy, which is a very basic init system. I hope that when he
does tackle it, "scripts" written in C as part of toybox would be
supported.

It's likely bit rotted horribly, but for the curious -

https://sourceforge.net/projects/urunlevel/

I'd be happy to port it to toybox.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
stephen Turner
2015-01-02 18:07:09 UTC
Permalink
Post by David Seikel
That's not entirely true. Many years ago I wrote an implementation of
runlevel/init.d/SYS V init applets for busybox, aiming for LSB
compliance. It included the ability for the actual "scripts"
themselves to be written in any language, and included several ones
written in C as busybox applets. These init "scripts" would just be
symlinks to busybox. This is in fact compliant with the LSB
specification.
If I remember correctly, it includes most of the good stuff systemd
claims, fast boot if all/most of the "scripts" are written in C,
dependency tracking, parallel "script" running, etc.
thats pretty cool. Since i started on this project i have started to adapt
a certain mentality of reusing whats on the system and trying to minimize
redundant code. During my self education today i read that the kernel is
supposed to call /sbin/init and recalling a snippet of LFS you can write a
script to replace init (to some degree or another). So i have been digging
for resources to do just that. My concern becomes "reaping" child processes
as i have heard here/musl-list several times and respawning of services
etc. Im not sure how much of this can be done in a script yet but Im still
digging through websites and such. I confess ive been a bit scatterbrained
today looking at a init script, systemd, sysv init, rcS script, etc.

what i do know is i need to thread everything i can as much as i can for
speed. I remember something about setting up init run levels a certain way
to do this but haven't refound that article yet. In general i want to
always keep as much of the system broken apart so it can be threaded as
possible to increase speed on todays multi thread-core systems. I have a
lot more reading to do before i will get there.
Isaac Dunham
2015-01-02 18:57:26 UTC
Permalink
Post by David Seikel
Post by stephen Turner
while doing some searches on scripting i was reminded about
"service" and noticed it wasn't in toybox. Is this a oversight or
not in intended feature/possible post 1.0.
service(8) is part of the rc scripts, of which there are more variants
than there are of init(8).
It makes little sense to include it in toybox when the only init we
have is oneit; even when init gets out of pending, implementing
service in toybox would be hard-coding a requirement about how the rc
scripts work. We certainly couldn't implement the rc scripts in
toybox, since they are scripts.
That's not entirely true. Many years ago I wrote an implementation of
runlevel/init.d/SYS V init applets for busybox, aiming for LSB
compliance. It included the ability for the actual "scripts"
themselves to be written in any language, and included several ones
written in C as busybox applets. These init "scripts" would just be
symlinks to busybox. This is in fact compliant with the LSB
specification.
If I remember correctly, it includes most of the good stuff systemd
claims, fast boot if all/most of the "scripts" are written in C,
dependency tracking, parallel "script" running, etc.
I'm...fascinated and revolted.
The problem with doing init scripts in C is that *when* it breaks (and
it will, since flawless hardware, drivers, kernel, libc, init, *and*
networking services exist nowhere), it will require either a rebuild
by someone who knows C, or a *replacement* by a user who only knows
shell. And writing a shell script to replace an init script while
fixing a bug is a lot more work than fixing a bug in a shell script.

However, having the tools required for init scripts done in C is
a significant improvement; killproc, pidofproc, etc. should not be
done in shell (as many init scripts do); they could probably be
implemented along with pkill/killall/... and pidof.
Post by David Seikel
Rob hasn't decided yet how to tackle this sort of thing, other than his
oneit toy, which is a very basic init system. I hope that when he
does tackle it, "scripts" written in C as part of toybox would be
supported.
It's likely bit rotted horribly, but for the curious -
https://sourceforge.net/projects/urunlevel/
I'd be happy to port it to toybox.
Thanks,
Isaac Dunham
Rob Landley
2015-01-04 23:57:16 UTC
Permalink
Post by Isaac Dunham
Post by David Seikel
If I remember correctly, it includes most of the good stuff systemd
claims, fast boot if all/most of the "scripts" are written in C,
dependency tracking, parallel "script" running, etc.
I'm...fascinated and revolted.
I'm researching init systems. I want to solve this problem _properly_
and provide generic infrastructure that actually does, in a non-crazy
way, what users are trying to get init systems to do.

Alas, one of the biggest use cases I have to look at is android init,
and the last time I did that they had a config file that _looked_ like a
shell script, but wasn't. So, I need to look at that until I understand
all of it.

And I need to read the old linux weekly news article series on what
upstart was trying to do, and track down the maintainer's blog posts
desribing the rewrite he's decided not to do (are there any?), AND read
the the lwn.net series Lennart "Ulrich Drepper TNG" Pottering wrote on
how systemd works, and I need to read up on how lxc's init process
works, and I need to read about MacOS X launchd which is what upstart
and systemd both started out by copying. (And take another stab at
figuring out what openrc was actually trying to _do_.)

And I'm not currently doing _any_ of that because there are a half dozen
things higher priority and I need to _focus_ on a project like that to
tease out the common elements.

Toybox contains a number of sub-issues that would each be a project in
themselves for somebody sane.
Post by Isaac Dunham
The problem with doing init scripts in C is that *when* it breaks (and
it will, since flawless hardware, drivers, kernel, libc, init, *and*
networking services exist nowhere), it will require either a rebuild
by someone who knows C, or a *replacement* by a user who only knows
shell. And writing a shell script to replace an init script while
fixing a bug is a lot more work than fixing a bug in a shell script.
However, having the tools required for init scripts done in C is
a significant improvement; killproc,
I need a kill -r that takes out all the descendant processes. It's on
the todo list...
Post by Isaac Dunham
pidofproc,
What would "pidofpric" do that toys/lsb/pidof.c doesn't?
Post by Isaac Dunham
etc. should not be
done in shell (as many init scripts do); they could probably be
implemented along with pkill/killall/... and pidof.
Post by David Seikel
Rob hasn't decided yet how to tackle this sort of thing, other than his
oneit toy, which is a very basic init system. I hope that when he
does tackle it, "scripts" written in C as part of toybox would be
supported.
It's likely bit rotted horribly, but for the curious -
https://sourceforge.net/projects/urunlevel/
I'd be happy to port it to toybox.
Someday I need to dredge up http://dvpn.sf.net/old and... I dunno, port
it to dropbear maybe?

Waaaaaaay down on the todo list...

Rob
stephen Turner
2015-01-05 00:50:47 UTC
Permalink
Hey Rob, Dalias wrote an article and i think i agree with it (I admittedly
may not know my out port from a hole in the ground but i have been doing a
lot of reading this weekend) where he talks about the issues with init and
pid 1. There he wrote a like 10 line init that only did what it absolutely
had to and then called rc. I certainly think it fits your "as little as
possible" mentality with this project and could be a good fit. it would be
one program i doubt you would ever touch again thats for sure. He licensed
it under a BSD but originally it was open so maybe he would offer us that
code (or you could modify it) ?

http://ewontfix.com/14/

Whats your thought about this minimalist init? all of the fancy bells and
whistles can be outsourced to something else im sure.
David Seikel
2015-01-05 04:04:16 UTC
Permalink
On Sun, 4 Jan 2015 19:50:47 -0500 stephen Turner
Post by stephen Turner
Hey Rob, Dalias wrote an article and i think i agree with it (I
admittedly may not know my out port from a hole in the ground but i
have been doing a lot of reading this weekend) where he talks about
the issues with init and pid 1. There he wrote a like 10 line init
that only did what it absolutely had to and then called rc. I
certainly think it fits your "as little as possible" mentality with
this project and could be a good fit. it would be one program i doubt
you would ever touch again thats for sure. He licensed it under a BSD
but originally it was open so maybe he would offer us that code (or
you could modify it) ?
http://ewontfix.com/14/
Whats your thought about this minimalist init? all of the fancy bells
and whistles can be outsourced to something else im sure.
I'm about half way through reading that article, but I think that's more
or less what the toybox oneit does already?
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
stephen Turner
2015-01-05 04:26:01 UTC
Permalink
Post by David Seikel
I'm about half way through reading that article, but I think that's more
or less what the toybox oneit does already?
I wouldnt know, I havent seen the code yet but I was under the impression
it just pulled up a term. Maybe instead of calling rc it calls a term?
Guess I should check the code then.
Rob Landley
2015-01-05 13:58:50 UTC
Permalink
Post by stephen Turner
Hey Rob, Dalias wrote an article and i think i agree with it (I
admittedly may not know my out port from a hole in the ground but i have
been doing a lot of reading this weekend) where he talks about the
issues with init and pid 1. There he wrote a like 10 line init that only
did what it absolutely had to and then called rc. I certainly think it
fits your "as little as possible" mentality with this project and could
be a good fit. it would be one program i doubt you would ever touch
again thats for sure. He licensed it under a BSD but originally it was
open so maybe he would offer us that code (or you could modify it) ?
http://ewontfix.com/14/
Whats your thought about this minimalist init? all of the fancy bells
and whistles can be outsourced to something else im sure.
I read that when it came out and I believe at least one thing in it was
him quoting me from earlier irc discussions on #musl. :)

We've been butting heads for years and he _does_ often convince me I'm
wrong. Here's such an example from 2006, you'll note toybox verror_msg()
in lib/lib.c is currently using strerror() instead of %m:

http://lists.busybox.net/pipermail/busybox/2006-June/056537.html

His minimal init isn't that far off from my oneit. (Mine implements
console switching to get a controlling tty for the child process, his
expects the child to do that.)

A week or two back we were talking about how to get pid 1 to export the
list of PID exits from reparent_to_init():

http://lists.landley.net/pipermail/toybox-landley.net/2014-December/003810.html

If dreamhost ever gets its darn web archive caught up there's more to
that conversation. (I have a really hard time navigating gmane's web
interface to actually _find_ any specific post.)

I haven't done it yet because I haven't figured out the best way to
export the data. (Writing to a pipe or fifo can block pid 1, not sure
how complicated I want to get trying to avoid that? If the pid 2 it's
talking to goes away or isn't keeping up with the incoming data due to
forkbomb or similar, there isn't actually a _good_ solution. I should
probably just do the simple version first and then wait for it to cause
somebody a problem requiring more code. The potential symptom is
unreaped zombies which isn't immediately game over, so... I guess if you
tell "oneit -f /dev/fifoname" and nobody's reading from it, that's pilot
error in your system setup? Maybe? (And if the program that _should_ be
reading from it is the command oneit ran, then oneit responds to it
exiting by relaunching it or rebooting anyway, so... Hmmm, write with a
timeout? I can do that with poll(), which gets me back to genericizing
the main loop in netcat. And in fact the write with a timeout would be
"oneit -w SECONDS" because it's more or less a "watchdog"... ) Although
if you're saying "I am writing to pid 2" then I could just have fd 3
contain the pipe I'm writing to, the child process can inherit a
filehandle. Dunno if that's cleaner or uglier than
/dev/globallyvisibilefilename

Anyway, as you can see there's some design work to do...

Rob
stephen Turner
2015-01-05 18:15:37 UTC
Permalink
Post by Rob Landley
I read that when it came out and I believe at least one thing in it was
him quoting me from earlier irc discussions on #musl. :)
We've been butting heads for years and he _does_ often convince me I'm
wrong. Here's such an example from 2006, you'll note toybox verror_msg()
http://lists.busybox.net/pipermail/busybox/2006-June/056537.html
Yea, looks like he can be a bit.... stubborn. But (and i hate to say it)
when your right, your right and im assuming he was wright (otherwise there
would have been another email of you quoting statistics right?)
Post by Rob Landley
His minimal init isn't that far off from my oneit. (Mine implements
console switching to get a controlling tty for the child process, his
expects the child to do that.)
A week or two back we were talking about how to get pid 1 to export the
I dont remember why but i want to say i didnt jump in because you guys were
talking about a level of programming/system processes that was over my head.
Post by Rob Landley
http://lists.landley.net/pipermail/toybox-landley.net/2014-December/003810.html
If dreamhost ever gets its darn web archive caught up there's more to
that conversation. (I have a really hard time navigating gmane's web
interface to actually _find_ any specific post.)
I haven't done it yet because I haven't figured out the best way to
export the data. (Writing to a pipe or fifo can block pid 1, not sure
how complicated I want to get trying to avoid that? If the pid 2 it's
talking to goes away or isn't keeping up with the incoming data due to
forkbomb or similar, there isn't actually a _good_ solution. I should
probably just do the simple version first and then wait for it to cause
somebody a problem requiring more code. The potential symptom is
unreaped zombies which isn't immediately game over, so... I guess if you
tell "oneit -f /dev/fifoname" and nobody's reading from it, that's pilot
error in your system setup? Maybe? (And if the program that _should_ be
reading from it is the command oneit ran, then oneit responds to it
exiting by relaunching it or rebooting anyway, so... Hmmm, write with a
timeout? I can do that with poll(), which gets me back to genericizing
the main loop in netcat. And in fact the write with a timeout would be
"oneit -w SECONDS" because it's more or less a "watchdog"... ) Although
if you're saying "I am writing to pid 2" then I could just have fd 3
contain the pipe I'm writing to, the child process can inherit a
filehandle. Dunno if that's cleaner or uglier than
/dev/globallyvisibilefilename
Anyway, as you can see there's some design work to do...
Rob
im sure as there are lots of choices in init systems there must be a
variety of ways you could set it up. I'm pushing for stability on my
system and frankly if i dont like your init i dont have to use it, thats
the beauty if linux that i love. But on the other hand I know your not
going to implement a full systemd because you and others dont like the
"lock in" that it apparently pushes.

your discussing what exactly here? that pid 1 would be the init/reaper and
pid 2 would try to retain control of the daemons?

And "a potential side effect is unreaped zombies", But when reading that
the daemons are typically backgrounded and expected to report to pid 1 that
also sounds like it leaves the system open to allow rogue daemons which
either don't get a pid (is that possible?) or decide not to report to pid
1. Im still learning the init process over all and fairly sure everything
gets a pid but so far my reading hasn't answered if a
backgrounded/daemonized service is forced to report to pid 1/init or not.
Isaac Dunham
2015-01-05 02:23:14 UTC
Permalink
Post by Rob Landley
Post by Isaac Dunham
However, having the tools required for init scripts done in C is
a significant improvement; killproc,
I need a kill -r that takes out all the descendant processes. It's on
the todo list...
Post by Isaac Dunham
pidofproc,
What would "pidofproc" do that toys/lsb/pidof.c doesn't?
pidofproc [-p PIDFILE] /path/to/daemon
looks for a pidfile (either PIDFILE or /var/run/daemon.pid),
reads the first line, if that line contains one or more numbers
separated by spaces, use them,
check that they are running, print any applicable pids,
and return 0 "if the program is running" (note the ambiguity about
what that means if multiple pids are found on line 1 of the pidfile!)

To check if it is still running, they imply that one could compare
/path/to/daemon to the start of /proc/$PID/cmdline or to /proc/$PID/exe.

If -p PIDFILE is not specified, you can add any way of searching for
additional pids you wish.

killproc looks like it was meant to be implemented thus:
killproc(){
for PID in `pidofproc "$1"`
do kill $PID $2 # note: $2 is optional
done
if [ -n "$2" ]
then
pidofproc >/dev/null || return 0
return 1
else
pidofproc >/dev/null
return $?
fi
}
Post by Rob Landley
Post by Isaac Dunham
etc. should not be
done in shell (as many init scripts do); they could probably be
implemented along with pkill/killall/... and pidof.
All of this is 20.8 in the generic LSB Core specification:
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html

HTH,
Isaac Dunham
Continue reading on narkive:
Loading...