top reports wrong process status + sudo kill -l -> crap?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

top reports wrong process status + sudo kill -l -> crap?

Sebastian Rother
Well I don`t know if it`s a Bug or not but I`ve noticed that if I do
suspend some processes and let them run later again (using the kill
command + signal) top displays a wrong output (permanently) as long as the
processes are still "alive" (not killed by kill -9 or temrinated with
other methods).

I`ve some nmaps running and stoped them using sudo kill -STOP `pgrep nmap`

Later I`ve started thos eprocesses again with sudo kill -CONT `pgrep nmap`
but top  does report this to me:

PID USERNAME PRI NICE  SIZE   RES STATE    WAIT     TIME    CPU COMMAND
9568 root       4    0 6160K 7608K sleep    bpf    134:28  0.00% nmap
17824 root       4    0   18M   19M sleep    bpf     73:31  0.00% nmap
30947 root       4    0   15M   17M sleep    bpf     54:55  0.00% nmap
21486 root       4    0   21M   23M sleep    bpf     53:56  0.00% nmap
19749 root       4    0   10M   11M sleep    bpf     51:08  0.00% nmap
28597 root       4    0   22M   24M sleep    bpf     31:11  0.00% nmap
19797 root       4    0   22M   24M sleep    bpf     21:14  0.00% nmap
 2745 root       4    0   11M   13M sleep    bpf     20:18  0.00% nmap

THose nmap processes aren`t sleeping and tcpdump proofs me right so top
seams to display wrong status informations.

Also the KILL command has some "display problems" if I do run it with sudo.

wizzard $ kill -l
 1    HUP Hangup                        9   KILL Killed                  
   17   STOP Suspended (signal)           25   XFSZ Filesize limit
exceeded
 2    INT Interrupt                    10    BUS Bus error                
   18   TSTP Suspended                    26 VTALRM Virtual timer expired
 3   QUIT Quit                         11   SEGV Segmentation fault      
   19   CONT Continued                    27   PROF Profiling timer
expired
 4    ILL Illegal instruction          12    SYS Bad system call          
   20   CHLD Child exited                 28  WINCH Window size changes
 5   TRAP Trace/BPT trap               13   PIPE Broken pipe              
   21   TTIN Stopped (tty input)          29   INFO Information request
 6   ABRT Abort trap                   14   ALRM Alarm clock              
   22   TTOU Stopped (tty output)         30   USR1 User defined signal 1
 7    EMT EMT trap                     15   TERM Terminated              
   23     IO I/O possible                 31   USR2 User defined signal 2
 8    FPE Floating point exception     16    URG Urgent I/O condition    
   24   XCPU Cputime limit exceeded
wizzard $ sudo kill -l
HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG
STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2

If I do run pkill -l as root (got root with sudo su to test it) the output
looks normal. But with sudo kill -l it`s kinda (compared to the table kill
-l provides) useless.

It would be neat if somebody could confirm this.
No matter what command I do use with top the output remains wrong
("sleep") So it does not matter if I do use -s 0.1 or something else.

OpenBSD: 3.9 STABLE x86 + all patches
If you need a dmesg please let me know.

Kind regards,
Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: top reports wrong process status + sudo kill -l -> crap?

Henning Brauer-3
* [hidden email] <[hidden email]> [2006-09-12 12:25]:

> Well I don`t know if it`s a Bug or not but I`ve noticed that if I do
> suspend some processes and let them run later again (using the kill
> command + signal) top displays a wrong output (permanently) as long as the
> processes are still "alive" (not killed by kill -9 or temrinated with
> other methods).
>
> I`ve some nmaps running and stoped them using sudo kill -STOP `pgrep nmap`
>
> Later I`ve started thos eprocesses again with sudo kill -CONT `pgrep nmap`
> but top  does report this to me:
>
> PID USERNAME PRI NICE  SIZE   RES STATE    WAIT     TIME    CPU COMMAND
> 9568 root       4    0 6160K 7608K sleep    bpf    134:28  0.00% nmap
> 17824 root       4    0   18M   19M sleep    bpf     73:31  0.00% nmap
> 30947 root       4    0   15M   17M sleep    bpf     54:55  0.00% nmap
> 21486 root       4    0   21M   23M sleep    bpf     53:56  0.00% nmap
> 19749 root       4    0   10M   11M sleep    bpf     51:08  0.00% nmap
> 28597 root       4    0   22M   24M sleep    bpf     31:11  0.00% nmap
> 19797 root       4    0   22M   24M sleep    bpf     21:14  0.00% nmap
>  2745 root       4    0   11M   13M sleep    bpf     20:18  0.00% nmap
>
> THose nmap processes aren`t sleeping and tcpdump proofs me right so top
> seams to display wrong status informations.

oh danger, these processes are sleeping most of the time!
please, finally try to stop making a fool out of yourself and learn
some unix basics. of course sleeping has nothing to do with sigstop.

> Also the KILL command has some "display problems" if I do run it with sudo.
>
> wizzard $ kill -l

shell builtin

> wizzard $ sudo kill -l

/bin/kill

different implementations.

> No matter what command I do use with top the output remains wrong
> ("sleep")

"wrong", hear hear.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

Reply | Threaded
Open this post in threaded view
|

Re: top reports wrong process status + sudo kill -l -> crap?

Otto Moerbeek
In reply to this post by Sebastian Rother
On Tue, 12 Sep 2006, [hidden email] wrote:

> Well I don`t know if it`s a Bug or not but I`ve noticed that if I do
> suspend some processes and let them run later again (using the kill
> command + signal) top displays a wrong output (permanently) as long as the
> processes are still "alive" (not killed by kill -9 or temrinated with
> other methods).
>
> I`ve some nmaps running and stoped them using sudo kill -STOP `pgrep nmap`
>
> Later I`ve started thos eprocesses again with sudo kill -CONT `pgrep nmap`
> but top  does report this to me:
>
> PID USERNAME PRI NICE  SIZE   RES STATE    WAIT     TIME    CPU COMMAND
> 9568 root       4    0 6160K 7608K sleep    bpf    134:28  0.00% nmap
> 17824 root       4    0   18M   19M sleep    bpf     73:31  0.00% nmap
> 30947 root       4    0   15M   17M sleep    bpf     54:55  0.00% nmap
> 21486 root       4    0   21M   23M sleep    bpf     53:56  0.00% nmap
> 19749 root       4    0   10M   11M sleep    bpf     51:08  0.00% nmap
> 28597 root       4    0   22M   24M sleep    bpf     31:11  0.00% nmap
> 19797 root       4    0   22M   24M sleep    bpf     21:14  0.00% nmap
>  2745 root       4    0   11M   13M sleep    bpf     20:18  0.00% nmap
>
> THose nmap processes aren`t sleeping and tcpdump proofs me right so top
> seams to display wrong status informations.

'sleep' means something different than 'stopped'.
Be glad most of your processes are sleeping most of the time. If
tcpdump processes are so busy they show up in state 'run' often, your
machine is probably overloaded with work.

>
> Also the KILL command has some "display problems" if I do run it with sudo.
>
> wizzard $ kill -l
>  1    HUP Hangup                        9   KILL Killed                  
>    17   STOP Suspended (signal)           25   XFSZ Filesize limit
> exceeded
>  2    INT Interrupt                    10    BUS Bus error                
>    18   TSTP Suspended                    26 VTALRM Virtual timer expired
>  3   QUIT Quit                         11   SEGV Segmentation fault      
>    19   CONT Continued                    27   PROF Profiling timer
> expired
>  4    ILL Illegal instruction          12    SYS Bad system call          
>    20   CHLD Child exited                 28  WINCH Window size changes
>  5   TRAP Trace/BPT trap               13   PIPE Broken pipe              
>    21   TTIN Stopped (tty input)          29   INFO Information request
>  6   ABRT Abort trap                   14   ALRM Alarm clock              
>    22   TTOU Stopped (tty output)         30   USR1 User defined signal 1
>  7    EMT EMT trap                     15   TERM Terminated              
>    23     IO I/O possible                 31   USR2 User defined signal 2
>  8    FPE Floating point exception     16    URG Urgent I/O condition    
>    24   XCPU Cputime limit exceeded
> wizzard $ sudo kill -l
> HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG
> STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2

That's the difference between the shell built-in kill and /bin/kill.

>
> If I do run pkill -l as root (got root with sudo su to test it) the output
> looks normal. But with sudo kill -l it`s kinda (compared to the table kill
> -l provides) useless.

Why is it useless? You can use signal names after all in the kill
command, like kill -QUIT pid.

>
> It would be neat if somebody could confirm this.
> No matter what command I do use with top the output remains wrong
> ("sleep") So it does not matter if I do use -s 0.1 or something else.

check

        while true; do : ; done

with top, it will show up in state 'run' almost all of the time.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: top reports wrong process status + sudo kill -l -> crap?

Marco Peereboom
In reply to this post by Sebastian Rother
You should from now on cc these to the dailywtf; more people would love to read
this kind of stuff!

On Tue, Sep 12, 2006 at 12:23:44PM +0200, [hidden email] wrote:

> Well I don`t know if it`s a Bug or not but I`ve noticed that if I do
> suspend some processes and let them run later again (using the kill
> command + signal) top displays a wrong output (permanently) as long as the
> processes are still "alive" (not killed by kill -9 or temrinated with
> other methods).
>
> I`ve some nmaps running and stoped them using sudo kill -STOP `pgrep nmap`
>
> Later I`ve started thos eprocesses again with sudo kill -CONT `pgrep nmap`
> but top  does report this to me:
>
> PID USERNAME PRI NICE  SIZE   RES STATE    WAIT     TIME    CPU COMMAND
> 9568 root       4    0 6160K 7608K sleep    bpf    134:28  0.00% nmap
> 17824 root       4    0   18M   19M sleep    bpf     73:31  0.00% nmap
> 30947 root       4    0   15M   17M sleep    bpf     54:55  0.00% nmap
> 21486 root       4    0   21M   23M sleep    bpf     53:56  0.00% nmap
> 19749 root       4    0   10M   11M sleep    bpf     51:08  0.00% nmap
> 28597 root       4    0   22M   24M sleep    bpf     31:11  0.00% nmap
> 19797 root       4    0   22M   24M sleep    bpf     21:14  0.00% nmap
>  2745 root       4    0   11M   13M sleep    bpf     20:18  0.00% nmap
>
> THose nmap processes aren`t sleeping and tcpdump proofs me right so top
> seams to display wrong status informations.
>
> Also the KILL command has some "display problems" if I do run it with sudo.
>
> wizzard $ kill -l
>  1    HUP Hangup                        9   KILL Killed                  
>    17   STOP Suspended (signal)           25   XFSZ Filesize limit
> exceeded
>  2    INT Interrupt                    10    BUS Bus error                
>    18   TSTP Suspended                    26 VTALRM Virtual timer expired
>  3   QUIT Quit                         11   SEGV Segmentation fault      
>    19   CONT Continued                    27   PROF Profiling timer
> expired
>  4    ILL Illegal instruction          12    SYS Bad system call          
>    20   CHLD Child exited                 28  WINCH Window size changes
>  5   TRAP Trace/BPT trap               13   PIPE Broken pipe              
>    21   TTIN Stopped (tty input)          29   INFO Information request
>  6   ABRT Abort trap                   14   ALRM Alarm clock              
>    22   TTOU Stopped (tty output)         30   USR1 User defined signal 1
>  7    EMT EMT trap                     15   TERM Terminated              
>    23     IO I/O possible                 31   USR2 User defined signal 2
>  8    FPE Floating point exception     16    URG Urgent I/O condition    
>    24   XCPU Cputime limit exceeded
> wizzard $ sudo kill -l
> HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG
> STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2
>
> If I do run pkill -l as root (got root with sudo su to test it) the output
> looks normal. But with sudo kill -l it`s kinda (compared to the table kill
> -l provides) useless.
>
> It would be neat if somebody could confirm this.
> No matter what command I do use with top the output remains wrong
> ("sleep") So it does not matter if I do use -s 0.1 or something else.
>
> OpenBSD: 3.9 STABLE x86 + all patches
> If you need a dmesg please let me know.
>
> Kind regards,
> Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: top reports wrong process status + sudo kill -l -> crap?

Otto Moerbeek
In reply to this post by Sebastian Rother
OK, I'll tell you something, since you do not seem to be able to find
that out yourself....

tcpdump is a privilege separated process. The process owned by root
mostly does name lookups. The answers are cached by the unprivileged
process owned by _tcpdump. That process does the interpreting and
printing, and indeed happily flops beteen 'run' and 'sleep', as can be
observed with top -s 0.01.

After tcpdump haas ben running for a while, the monitor has almost
nothing left to do, since almost all addresses are alreacy cached.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: top reports wrong process status + sudo kill -l -> crap?

Otto Moerbeek
On Tue, 12 Sep 2006, Otto Moerbeek wrote:

> OK, I'll tell you something, since you do not seem to be able to find
> that out yourself....
>
> tcpdump is a privilege separated process. The process owned by root
> mostly does name lookups. The answers are cached by the unprivileged
> process owned by _tcpdump. That process does the interpreting and
> printing, and indeed happily flops beteen 'run' and 'sleep', as can be
> observed with top -s 0.01.
>
> After tcpdump haas ben running for a while, the monitor has almost
> nothing left to do, since almost all addresses are alreacy cached.

Oops, you were actually talking about nmap. Sorry for the noise.

        -Otto