Subject: How to forcibly abort a command in a terminal window?

From: Richard Owlett <[email-masked]>
Date: Mon, 5 Sep 2016 06:46:16 -0500

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

---

From: Henrique de Moraes Holschuh <[email-masked]>
Date: Mon, 5 Sep 2016 09:28:44 -0300

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

---

From: Richard Owlett <[email-masked]>
Date: Mon, 5 Sep 2016 08:13:03 -0500

> 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 ;/

---

From: Jonathan Dowland <[email-masked]>
Date: Mon, 5 Sep 2016 14:35:12 +0100

> 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).

---

From: Richard Owlett <[email-masked]>
Date: Mon, 5 Sep 2016 09:06:27 -0500

> 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 ;/

---

From: Charlie Kravetz <[email-masked]>
Date: Mon, 5 Sep 2016 07:42:59 -0700

On Mon, 5 Sep 2016 09:06:27 -0500

>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]

---

From: Nicolas George <[email-masked]>
Date: Mon, 5 Sep 2016 17:19:38 +0200

> always instant, but faster than ctrl-c for some things, including rsync

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

---

From: Charlie Kravetz <[email-masked]>
Date: Mon, 5 Sep 2016 09:27:06 -0700

On Mon, 5 Sep 2016 17:19:38 +0200

>cases, even though this is not the purpose of SIGQUIT.

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

---

From: Vincent Lefevre <[email-masked]>
Date: Mon, 5 Sep 2016 21:22:56 +0200

> 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 <[email-masked]> - 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)

---

From: Dutch Ingraham <[email-masked]>
Date: Mon, 5 Sep 2016 11:13:35 -0500

> 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."

---

From: Nicolas George <[email-masked]>
Date: Mon, 5 Sep 2016 18:37:42 +0200

> The last sentence is inaccurate and imprecise.  See man 7 signal, and esp. under

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