| Age | Commit message (Collapse) | Author |
|---|
|
It makes busybox invoke the libselinux library function to load the binary
policy right at system start-up. It was successfully tested on a mini-SELinux
system. Note: requires recent libselinux. I'm using 1.28.
|
|
we actually need to spawn something on it.
|
|
the busybox binary) into enums (which don't).
|
|
definitions. (That should only be on prototypes.)
|
|
|
|
|
|
|
|
else is a kernel bug. Both 2.4 and 2.6 should get this right now. This
should fix the bug IraquiGeek is seeing (although killall still needs to
be fixed.)
|
|
|
|
|
|
|
|
init shouldn't call swapoff.
|
|
0000024 03-16-05 patch: allow init to set controlling tty
|
|
|
|
* init/init.c: Do not include sys/mount.h.
(message): Use O_NONBLOCK instead of O_NDELAY.
(console_init): Ditto.
|
|
* init/Config.in (CONFIG_FEATURE_INIT_SWAPON): New option.
* init/init.c (check_memory): Disable the swapon feature unless
CONFIG_FEATURE_INIT_SWAPON is defined.
|
|
|
|
The init applet will restart (re-exec) itsself when it
receives a SIGHUP. However, just before it enters its
main loop, it resets SIGHUP to either re-load the inittab
(or ignore it if no inittab is used). Thus preventing
the re-exec option from being triggerable.
This patch adds a signal handler for SIGQUIT for init that
always causes init to re-exec itsself (along with killing
anything else that might be still running).
|
|
Hello, all.
Busybox init does not handle removed inittab entry correctly.
# I'm sorry about my poor english, but you can find
# what I would like to say from patch, isn't it?
even if you apply this path,
when yoy try to change a command line option in inittab,
you have to do following steps.
1. remove old line from initrd
2. send HUP signal to init
3. kill old proces which is invoked from init.
4. append new line to inittab
5. send HUP signal to init, again
patch is against current CVS + last patch witch I send it last.
|
|
"kill -HUP 1" reloads inittab, and when I append one line to inittab
and send HUP signal two times, It will starts 2 process.
patch against current CVS is attached.
|
|
askfirst when mmuless.
|
|
On Sat, Jun 19, 2004 at 10:57:37PM +0200, Bastian Blank wrote:
> The following patch changes klogd to use openlog/syslog themself
> instead of calling syslog_msg which always calls the triple
> openlog/syslog/closelog.
Updated patch: get rid of syslog_msg entirely. Request from Erik Andersen.
Bastian
|
|
|
|
contain only actions sysinit/wait/once. It does not clean up zombies
in that case.
|
|
It looks like latest uClibc defines ARCH_HAS_MMU, but a few busybox files
test UCLIBC_HAS_MMU, resulting in vfork() getting called instead of
fork(), etc.
Patch below. Only tested for lash.
Cheers,
-Jamie
|
|
|
|
Fix two race conditions, as described at.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=212764
|
|
Carefully cast to unsigned long long prior to multiply to get
the expected result.
|
|
to avoid stack corruption problems on some 64bit architectures
when sizeof(void*) != sizeof(int). Thanks to Atsushi Nemoto
for finding this problem.
|
|
patch from Thomas Gleixner to init.
Viodz last_patch_108
|
|
constant.
Vodz last_patch_107
|
|
a cast and for greater accuracy.
|
|
>I'm sure that no user process use old root now, but when run "umount
>/old_root", it says:
> umount: /old_root: Device or resource busy
>
>I have tried to remount /proc within the new root *after* chroot, but
>get the same result.
>
>
I found the problem, I said that no user process use old root when run
my scripts, but
I'm wrong, actually there is a '3' fd open the file
"/old_root/dev/console". By adding
debug message in init/init.c, I found the problem: when init restart(in
exec_signal()),
before open the new terminal device, there is still a file opened(I
don't know which file it is), so the
terminal device(stdin) get fd '1', and the first dup(0)(stdout) return
'2', the second(stderr) return '3'.
I attach a simple patch to solve this problem.
|
|
reparented to init...
|
|
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
|
|
kernel versions
|
|
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
|
|
|
|
|
|
N. Oleynik
|
|
reaping child processes better.
-Erik
|
|
|
|
earlier so I don't screw up such easy stuff.
-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).
|
