[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