[BusyBox 0005004]: Shell command will hang minicom. When minicom is hanging, reboot/poweroff commands are useless
bugs at busybox.net
bugs at busybox.net
Fri Sep 19 23:22:51 UTC 2008
A NOTE has been added to this issue.
======================================================================
http://busybox.net/bugs/view.php?id=5004
======================================================================
Reported By: xmuchgw
Assigned To: BusyBox
======================================================================
Project: BusyBox
Issue ID: 5004
Category: Other
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
======================================================================
Date Submitted: 09-15-2008 22:08 PDT
Last Modified: 09-19-2008 16:22 PDT
======================================================================
Summary: Shell command will hang minicom. When minicom is
hanging, reboot/poweroff commands are useless
Description:
package:busybox
version:1.10.2
When I execute following shell script on my development board in
HyperTerminal,
about 5~30 minuters later, the HyperTerminal hangs until press any key
from keyboard.
while true
do
ls -l
done
When my HyperTerminal is hanging, I login my development board by telnet.
And found that, reboot and power commands are NOT workable.
But others shell commands, such as cd/ls/ps are workable.
======================================================================
----------------------------------------------------------------------
Vladimir - 09-15-08 22:35
----------------------------------------------------------------------
Looks like system resources hunger.
Try
while true
do
ls -l
free
done
Is free memory decreasing?
----------------------------------------------------------------------
vda - 09-16-08 14:34
----------------------------------------------------------------------
Regarding your "killall init" strace. It definitely working correctly - it
signaled init with TERM:
# /strace -fF killall init
execve("/usr/bin/killall", ["killall", "init"], [/* 12 vars */]) = 0
...
close(3) = 0
kill(1, SIGTERM) = 0
exit_group(0) = ?
so the reason why init does not reboot, is somewhere in init code (or in
the script run from init when it gets TERM).
----------------------------------------------------------------------
vda - 09-16-08 14:38
----------------------------------------------------------------------
While you run this:
while true; do ls -l; done
can you determine which telnetd process is responsible for this session,
and run "strace -tt -o telnetd.log -p <telnetd's_pid>" until this hang
happens? Attach resulting log to this bug. (You may want to daemonize
strace process so that it does not require a separate telnet connection to
be open).
----------------------------------------------------------------------
xmuchgw - 09-16-08 19:02
----------------------------------------------------------------------
1)When I run the script as follow
while true
do
ls -l
free
done
Found the free memory is not decreasing.
2)I think halt.c has sent the SIGTERM signal to the init process.
But init process can not receive the signal. Because my debug messages in
init.c are not printed.
3)HyperTerminal/minicom is connected with development board's ttyS0. I run
the script in HyperTerminal/minicom, not in telnet terminal. When the
HyperTerminal/minicom hangs, I open a telnet terminal to run "strace -tt
-o telnetd.log -p <telnetd's_pid> &". And then run reboot. Look at the
attached telnetd.log please.
----------------------------------------------------------------------
vda - 09-18-08 15:31
----------------------------------------------------------------------
> Because my debug messages in init.c are not printed.
Can you show what messages did you add there? (Simply attach a patch to
this bug).
----------------------------------------------------------------------
vda - 09-18-08 15:36
----------------------------------------------------------------------
> 3)HyperTerminal/minicom is connected with development board's ttyS0. I
run the script in HyperTerminal/minicom, not in telnet terminal.
Aha, so the the session over serial link hangs, not telnet session. What
program is uses to initiate this session? getty or something else?
> When the HyperTerminal/minicom hangs, I open a telnet terminal to run
"strace -tt -o telnetd.log -p <telnetd's_pid> &". And then run reboot.
strace serial session then, not telnetd. "strace -tt -o serial.log -f -p
<ash's pid> &". And start strace BEFORE you run "while" loop, because you
need to capture the moment it hangs.
> Look at the attached telnetd.log please.
Because you straced your own telnetd session, I just see "reboot" being
run there. Not useful.
----------------------------------------------------------------------
xmuchgw - 09-18-08 23:26
----------------------------------------------------------------------
>Aha, so the the session over serial link hangs, not telnet session. What
program is uses to initiate this session? getty or something else?
The driver of my serial is 8250.c base on linux kernel 2.6.23. My
/etc/inittab is as follow:
# Note: BusyBox init works just fine without an inittab. If no inittab is
# found, it has the following default behavior:
::sysinit:/etc/init.d/rcS
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
# Start an "askfirst" shell on the console (whatever that may be)
::askfirst:-/bin/sh
>strace serial session then, not telnetd. "strace -tt -o serial.log -f -p
<ash's pid> &". And start strace BEFORE you run "while" loop, because you
need to capture the moment it hangs.
Because the output message is too much. I only list the bottom message
in serial.log file. Look at the attached serial.log please
>Can you show what messages did you add there? (Simply attach a patch to
this bug).
Please look at the init.c.patch.
----------------------------------------------------------------------
vda - 09-19-08 16:22
----------------------------------------------------------------------
> The driver of my serial is 8250.c base on linux kernel 2.6.23. My
/etc/inittab is as follow:
> ::askfirst:-/bin/sh
So it's a bare shell. Hmm. Try "exec getty <baudrate> -" and log in from
resulting login prompt. Now run the test, does it still hang? (getty does
some tty setup, maybe it would help).
>> strace serial session
> Because the output message is too much. I only list the bottom message
in serial.log file. Look at the attached serial.log please
It shows that last write() syscall has blocked, as if kernel thinks the
buffer is full or something like that.
> Please look at the init.c.patch.
static void halt_reboot_pwoff(int sig)
{
const char *m;
int rb;
+ printf(__FILE__" [line: %d]\n", __LINE__);
+ message(L_CONSOLE | L_LOG, "[chgw] in function
halt_reboot_pwoff!");
Not reliable if serial line is already bothched. may block.
+#ifdef R_DBG
+ printf(__FILE__" [line: %d] enable R_DBG\n", __LINE__);
+ if((dbg_fd=open("debug.log", O_WRONLY |O_TRUNC | O_CREAT |
O_SYNC)) < 0)
Good idea to write a file to disk.
You forgot the mode (3rd param): open(name, O_xxx, 0666)
BTW, in strace I see that "debug.log" indeed exists. So signal handler in
init.c _is reached_.
+ if(5 != write(dbg_fd, "11111", 5))
+ {
+ printf("open write 11111 error\n");
+ }
Don't bother with error checks. just use write(dbg_fd, "11111", 5), it's
just debugging after all.
Add more such write's to find out where it stops in init.c
Issue History
Date Modified Username Field Change
======================================================================
09-15-08 22:08 xmuchgw New Issue
09-15-08 22:08 xmuchgw Status new => assigned
09-15-08 22:08 xmuchgw Assigned To => BusyBox
09-15-08 22:35 Vladimir Note Added: 0011484
09-16-08 01:42 xmuchgw File Added: 2008-09-16.txt
09-16-08 14:34 vda Note Added: 0011494
09-16-08 14:38 vda Note Added: 0011504
09-16-08 18:51 xmuchgw Note Added: 0011514
09-16-08 19:01 xmuchgw Note Edited: 0011514
09-16-08 19:02 xmuchgw Note Edited: 0011514
09-16-08 19:19 xmuchgw File Added: telnetd.log
09-18-08 15:31 vda Note Added: 0011614
09-18-08 15:36 vda Note Added: 0011624
09-18-08 23:24 xmuchgw File Added: init.c.patch
09-18-08 23:25 xmuchgw File Added: serial.log
09-18-08 23:26 xmuchgw Note Added: 0011654
09-19-08 16:22 vda Note Added: 0011694
======================================================================
More information about the busybox-cvs
mailing list