Here's a pretty crude patch to reload /etc/inittab when init receives a
SIGHUP. The mailing list archives weren't entirely clear on whether or
not it should already happen, but didn't appear to be.
The patch:
* Adds a new function, reload_signal() which just calls
parse_inittab() and run_actions(RESPAWN)
* Before entering the while (1) loop set up SIGHUP to call
reload_signal()
* Modify new_init_action to skip the action if the same command
already exists on the same terminal
This last bit means that changing already running entries is a bit
hairy as you can end up with, for example, two shells running on the
same virtual console. However, for solely adding/removing entries this patch
seems to work quite well.
I've found a problem with job control when the init process is restarted.
If the system boots for the first time, I get job control on a serial terminal -
no problems. However, when I restart init by issuing "init -q", then the shell
no longer has job control.
I traced this a problem in console_init in the file init.c. What was happening
after the restart is that the first compare
if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
...
} else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
...
} else {
... // assume /dev/console
}
returned error and subsequently the code assumes /dev/console as the console,
which does not support job control.
Checking the errno after the first call showed that the system was complaining
about the file descriptor. This is probably because the previous init process
had closed all its file descriptors which the new init process had inherited.
andersen@busybox.net wrote:
>Message: 4
>Modified Files:
> init.c
>Log Message:
>Remove code for unsupported kernel versions
Hmm. Current init.c have check >= 2.2.0 kernel one time too.
Ok. Last patch removed this point and move common init code to new file for
/init dir
over the years. Well I finally took the time to track this down. It turns out
that inside linux/kernel/sys.c the kernel will call
machine_halt();
do_exit(0);
when halting, or will call
machine_power_off();
do_exit(0);
during a reboot. Unlike sysv init, we call reboot from within the init
process, so if the call to machine_halt() or machine_power_off() returns, the call to do_exit(0) will cause the kernel to panic. Which is a very
bad thing to happen.
So I just added this little patch to fork and call the reboot
syscall from within the forked child process, thereby neatly
avoiding the problem.
But IMHO, both calls to do_exit(0) within linux/kernel/sys.c
are bugs and should be fixed.
-Erik
best way to go. Sysvinit does not provide a controlling tty since it doesn't
even try to open ttys for apps. We do. So we should _try_ to provide a
controlling tty if possible, but we needn't freak out if it doesn't work. This
way we won't need to use openvt or similar, we'll just have init do the Right
Thing(tm).
New complex patch for decrease size devel version. Requires previous patch.
Also removed small problems from dutmp and tar applets.
Also includes vodz' last_patch61_2:
Last patch correcting comment for #endif and more integrated
with libbb (very reduce size if used "cat" applet also).
Requires last_patch61 for modutils/config.in.
control turned off" bug, console_setup() was called with a closed file
descriptor, setsid() inconsistancy, and silly string handling bugs. I have
modified his patch to allow the askfirst init actions to have a controlling
terminal.
1st makes init smaller, and fixes a bug with AskFirst. Reading from
/dev/null gives EOF.
2nd makes init run the command's in the order of inittab, as in
FIFO instead of LIFO.
