bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SIGSTOP and bash's time built-in


From: Stefan Tauner
Subject: SIGSTOP and bash's time built-in
Date: Mon, 26 Oct 2015 16:59:06 +0100

Hi,

I was creating some exercises for my students when I noticed very
strange behavior of the time built-in when sending SIGSTOP to a timed
command interactively (via ^Z):

$ time sleep 5
^Z
[1]+  Stopped                 sleep 5

real    0m0.880s
user    0m0.002s
sys     0m0.000s
$ ps Tf
  PID TTY      STAT   TIME COMMAND
31049 pts/21   Ss     0:00 bash
30828 pts/21   T      0:00  \_ sleep 5
30829 pts/21   R+     0:00  \_ ps Tf
$

As you can see, the time command prints the statistics when the signal
is received instead of when the sleep command actually finishes. The
same happens if I send SIGSTOP with kill(1) to the sleep process.
However, other signals seem to work fine (tested with a C program with
an empty SIGINT handler), i.e. the signal is correctly received by the
command and time waits until the command actually finishes.

The actual (/usr/bin/)time binary on my system handles ^Z correctly:
$ env time sleep 5
^Z
[1]+  Stopped                 env time sleep 5
$ fg
env time sleep 5
0.00user 0.00system 0:05.00elapsed 0%CPU (0avgtext+0avgdata
676maxresident)k
0inputs+0outputs (0major+215minor)pagefaults 0swaps
$

When I do the same with a process running in the background it also
works correctly (I presume because it starts a subshell that does the
signal handling?):

$ time sleep 10 &
[1] 31115
$ kill -SIGSTOP %1

[1]+  Stopped                 time sleep 10
$ kill -SIGCONT %1
$ 
real    0m10.002s
user    0m0.000s
sys     0m0.002s

[1]+  Done                    time sleep 10
$

The problem was also reported a long time ago against Debian's bash:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399076
But I could not find any other references so I guess it has never
reached an upstream bug tracker/ml.

I have briefly looked at the code... but there are way too much
recursions in execute_pipeline() and signal handling all over the place
that I'd rather not touch it yet. :) However, if you'd give me some
pointers I can look into it.

KR
-- 
Dipl.-Ing. Stefan Tauner
Research and Development
Embedded Systems Department

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 6, 1200 Vienna, Austria
T: +43 1 333 40 77-316
E: stefan.tauner@technikum-wien.at
I: embsys.technikum-wien.at
I: www.technikum-wien.at



reply via email to

[Prev in Thread] Current Thread [Next in Thread]