Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #171753 > unrolled thread

How to forcibly abort a command in a terminal window?

Back to article view | Back to linux.debian.user

Contents

  How to forcibly abort a command in a terminal window? Richard Owlett <rowlett@cloud85.net> - 2016-09-05 13:50 +0200
    Re: How to forcibly abort a command in a terminal window? Henrique de Moraes Holschuh <hmh@debian.org> - 2016-09-05 14:30 +0200
      Re: How to forcibly abort a command in a terminal window? Richard Owlett <rowlett@cloud85.net> - 2016-09-05 15:20 +0200
        Re: How to forcibly abort a command in a terminal window? Jonathan Dowland <jmtd@debian.org> - 2016-09-05 15:40 +0200
          Re: How to forcibly abort a command in a terminal window? Richard Owlett <rowlett@cloud85.net> - 2016-09-05 16:10 +0200
            Re: How to forcibly abort a command in a terminal window? Charlie Kravetz <cjk@teamcharliesangels.com> - 2016-09-05 17:10 +0200
              Re: How to forcibly abort a command in a terminal window? Nicolas George <george@nsup.org> - 2016-09-05 17:20 +0200
                Re: How to forcibly abort a command in a terminal window? Dutch Ingraham <stoa@gmx.us> - 2016-09-05 18:20 +0200
                  Re: How to forcibly abort a command in a terminal window? Nicolas George <george@nsup.org> - 2016-09-05 18:40 +0200
                Re: How to forcibly abort a command in a terminal window? Charlie Kravetz <cjk@teamcharliesangels.com> - 2016-09-05 18:30 +0200
                  Re: How to forcibly abort a command in a terminal window? Vincent Lefevre <vincent@vinc17.net> - 2016-09-05 21:40 +0200

#171753 — How to forcibly abort a command in a terminal window?

The problem occurred when using cp to copy contents of one 
partition to another.
I realized I had miss-specified options. As data was multiple GB 
and target was a USB connected flash drive I wished an immediate 
termination.

Cntl-C had no apparent result.
Closing terminal window apparently did not abort operation - as 
indicated by activity light on flash drive continuing to blink.
Unmounting device worked.

It seems there should be a better option?
TIA

[toc] | [next] | [standalone]

#171755

On Mon, 05 Sep 2016, Richard Owlett wrote:
> I realized I had miss-specified options. As data was multiple GB and target
> was a USB connected flash drive I wished an immediate termination.

Usually there is no clean way to do this, and you have to wait for the
process to notice the signal, and abort.

> It seems there should be a better option?

There is none, at least for "cp" and just about everything else that
does normal writes (i.e. not direct I/O bypassing the kernel page
cache).

Maybe doing direct I/O using "dd o=direct" with a suitable (not too big)
buffer size would work differently, but I am not sure about that at all.

Anyway, from what you described, a lot of data to write was already
submitted by "cp" to the kernel, and the "cp" process would be in "D"
(uninterruptible sleep) state because it accumulated too many dirty
pages (pending writes) already and was still trying to queue up more
writes.

Eventually, the kernel would have flushed enough data to the device and
would decide to waken "cp" up to get more data to write, at which point
"cp" would notice the SIGINT from ^C, and abort.  The kernel would
continue to flush the remaining data that had already been submitted for
writing, though, so device writes would not immediately stop.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#171768

On 9/5/2016 7:28 AM, Henrique de Moraes Holschuh wrote:
> On Mon, 05 Sep 2016, Richard Owlett wrote:
>> I realized I had miss-specified options. As data was multiple GB and target
>> was a USB connected flash drive I wished an immediate termination.
>
> Usually there is no clean way to do this, and you have to wait for the
> process to notice the signal, and abort.
>
>> It seems there should be a better option?
>
> There is none, at least for "cp" and just about everything else that
> does normal writes (i.e. not direct I/O bypassing the kernel page
> cache).
>
> Maybe doing direct I/O using "dd o=direct" with a suitable (not too big)
> buffer size would work differently, but I am not sure about that at all.
>
> Anyway, from what you described, a lot of data to write was already
> submitted by "cp" to the kernel, and the "cp" process would be in "D"
> (uninterruptible sleep) state because it accumulated too many dirty
> pages (pending writes) already and was still trying to queue up more
> writes.
>
> Eventually, the kernel would have flushed enough data to the device and
> would decide to waken "cp" up to get more data to write, at which point
> "cp" would notice the SIGINT from ^C, and abort.  The kernel would
> continue to flush the remaining data that had already been submitted for
> writing, though, so device writes would not immediately stop.
>

Thank you.
Sometimes harware reset is the only thing.
The cp command was crudded up by human error ;/

[toc] | [prev] | [next] | [standalone]

#171770

[Multipart message — attachments visible in raw view] — view raw

On Mon, Sep 05, 2016 at 08:13:03AM -0500, Richard Owlett wrote:
> Thank you.
> Sometimes harware reset is the only thing.
> The cp command was crudded up by human error ;/

Your ^C would eventually be honoured by cp. The result will be an incomplete
copy, but the filesystem should be in a consistent state. Performing a hardware
reset could result in filesystem corruption (which a journalled filesystem
would correct: but not something like FAT32 as commonly used on USB sticks).

[toc] | [prev] | [next] | [standalone]

#171773

On 9/5/2016 8:35 AM, Jonathan Dowland wrote:
> On Mon, Sep 05, 2016 at 08:13:03AM -0500, Richard Owlett wrote:
>> Thank you.
>> Sometimes harware reset is the only thing.
>> The cp command was crudded up by human error ;/
>
> Your ^C would eventually be honoured by cp. The result will be an incomplete
> copy, but the filesystem should be in a consistent state. Performing a hardware
> reset could result in filesystem corruption (which a journalled filesystem
> would correct: but not something like FAT32 as commonly used on USB sticks).
>

<GRIN> promptness of abort was higher priority than file system 
integretity.
I date from 8085 being a new device ;/

[toc] | [prev] | [next] | [standalone]

#171779

On Mon, 5 Sep 2016 09:06:27 -0500
Richard Owlett <rowlett@cloud85.net> wrote:

>On 9/5/2016 8:35 AM, Jonathan Dowland wrote:
>> On Mon, Sep 05, 2016 at 08:13:03AM -0500, Richard Owlett wrote:  
>>> Thank you.
>>> Sometimes harware reset is the only thing.
>>> The cp command was crudded up by human error ;/  
>>
>> Your ^C would eventually be honoured by cp. The result will be an incomplete
>> copy, but the filesystem should be in a consistent state. Performing a hardware
>> reset could result in filesystem corruption (which a journalled filesystem
>> would correct: but not something like FAT32 as commonly used on USB sticks).
>>  
>
><GRIN> promptness of abort was higher priority than file system 
>integretity.
>I date from 8085 being a new device ;/
>
>

I open a second terminal, then use ps -A to find the command. I can
kill it with "sudo kill ????" which kills the job number. It is not
always instant, but faster than ctrl-c for some things, including rsync
and cp .

-- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

[toc] | [prev] | [next] | [standalone]

#171780

[Multipart message — attachments visible in raw view] — view raw

Le decadi 20 fructidor, an CCXXIV, Charlie Kravetz a écrit :
> I open a second terminal, then use ps -A to find the command. I can
> kill it with "sudo kill ????" which kills the job number. It is not
> always instant, but faster than ctrl-c for some things, including rsync
> and cp .

Not true.

The only difference between your method and kill is that kill will send
SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
default. But both have the same default action of interrupting the process.

cp does not handle signals explicitly, leaving them to their default
behaviour. rsync catches signals, but with the same handler for SIGINT and
SIGTERM. Therefore, the effect of Ctrl-C and kill on both is exactly the
same. The difference you observe is certainly only psychological.

Note that the same does not apply to "kill -9": SIGKILL, number 9, can not
be caught by processes. Yet, since cp does not catch signals, Ctrl-C, kill
or kill -9 will have the same effect. On rsync, "kill -9" will prevent it
from cleaning up temp files, which can be a life saver if you forgot the -P
option and already copied a big chunk of data over a slow link.

Also note that other applications may behave differently. I have noticed
that Python applications using Qt ignore SIGINT for no apparent reason
except annoy developers. Knowing ^\, i.e. SIGQUIT, is useful in that kind of
cases, even though this is not the purpose of SIGQUIT.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#171783

On Mon, Sep 05, 2016 at 05:19:38PM +0200, Nicolas George wrote:
> Le decadi 20 fructidor, an CCXXIV, Charlie Kravetz a écrit :
> SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
> default. But both have the same default action of interrupting the process.

The last sentence is inaccurate and imprecise.  See man 7 signal, and esp. under
the column "Action."

[toc] | [prev] | [next] | [standalone]

#171787

[Multipart message — attachments visible in raw view] — view raw

Le decadi 20 fructidor, an CCXXIV, Dutch Ingraham a écrit :
> > SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
> > default. But both have the same default action of interrupting the process.
> The last sentence is inaccurate and imprecise.  See man 7 signal, and esp. under
> the column "Action."

I indeed misremembered the number for SIGINT; thanks for noticing. With that
mistake fixed, I think my sentence becomes exact.

[toc] | [prev] | [next] | [standalone]

#171784

On Mon, 5 Sep 2016 17:19:38 +0200
Nicolas George <george@nsup.org> wrote:

>Le decadi 20 fructidor, an CCXXIV, Charlie Kravetz a écrit :
>> I open a second terminal, then use ps -A to find the command. I can
>> kill it with "sudo kill ????" which kills the job number. It is not
>> always instant, but faster than ctrl-c for some things, including rsync
>> and cp .  
>
>Not true.
>
>The only difference between your method and kill is that kill will send
>SIGTERM (number 15) by default while Ctrl-C sends SIGINT (number 3) by
>default. But both have the same default action of interrupting the process.
>
>cp does not handle signals explicitly, leaving them to their default
>behaviour. rsync catches signals, but with the same handler for SIGINT and
>SIGTERM. Therefore, the effect of Ctrl-C and kill on both is exactly the
>same. The difference you observe is certainly only psychological.
>
>Note that the same does not apply to "kill -9": SIGKILL, number 9, can not
>be caught by processes. Yet, since cp does not catch signals, Ctrl-C, kill
>or kill -9 will have the same effect. On rsync, "kill -9" will prevent it
>from cleaning up temp files, which can be a life saver if you forgot the -P
>option and already copied a big chunk of data over a slow link.
>
>Also note that other applications may behave differently. I have noticed
>that Python applications using Qt ignore SIGINT for no apparent reason
>except annoy developers. Knowing ^\, i.e. SIGQUIT, is useful in that kind of
>cases, even though this is not the purpose of SIGQUIT.
>
>Regards,
>

Psychological or not, it certainly works for me. By killing the job
number, it forces it to stop on my computer. 

-- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

[toc] | [prev] | [next] | [standalone]

#171799

On 2016-09-05 09:27:06 -0700, Charlie Kravetz wrote:
> Psychological or not, it certainly works for me. By killing the job
> number, it forces it to stop on my computer. 

Yes, on *your* computer. But for the OP, it appears that the
process was not killable (yet), probably because it was in
kernel mode.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web