How to stop SRM Linux?

Question

I'm using SRM to delete one file. Already 12 hours srm is working for deleting a 7GB file and it have only 3 stars ***

Is there a way to stop it or to pause so I do that another day.

Answer 1

A crash-course to killing command-line / text-mode programs

To elaborate on @AFH's comment, if "SRM" is a console (command-line interface) program, and you have run it from a terminal, just hit Ctrl-z, as this makes your terminal send the foreground process it manages that SIGSTOP signal and send it to the background. You can then "bring it back" by executing the fg shell command—it's a part of the so-called "job control" implemented by interactive shells and means bringing the backgrounded process to foreground (hence "fg") which includes sending the process the SIGCONT signal among other things.

Of course, to stop a process just, stop it. On Unix-y systems, including Linux-based OSes, this is done by sending the process one of special signals—usually SIGTERM or SIGINT. Hitting Ctrl-c in a terminal which runs a process makes that send the process the SIGINT signal. The kill program may be used to send arbitrary processes arbitrary signals.

The problem with using kill is that for most of its uses it requires the user to know the so-called "PID" of the process to send the signal to. PID is a Process IDentifier—an integer number ≥ 1 unique across all the processes currently managed by the OS.

The shell's job control makes it easier as it has certain mnemonics to refer to the processes it manages: if you background the currently active process by hitting Ctrl-z, you can then use the jobs command to see the list of processes managed by that shell. For example, I've just suspended an instance of mutt and run jobs after that; here's what I see:

~$ jobs
[1]+  Stopped                 mutt

Notice that [1]+ bit. The 1 is the job identifier assigned to that process by the shell. The + is a "handle" to refer to the last backgrounded process.

So you can now use either %1 or %+ with the kill command to refer to that process, like in

$ kill %1

or

$ kill %+

…and they will all send SIGTERM to that single backgrounded process.

That's how you can kill a misbehaving console program.

More on singals

Note that those SIGINT and SIGTERM signals can be "handled" by the process which received one of them. This allows the process to perform certain cleanup actions before quitting.

But sometimes a process might "hang" — say by executing an endless loop on a CPU due to a programming bug or by being stuck by trying to read/write from/to a file on some "dead" resource such as disconnected network share. In these cases delivering SIGINT or SIGTERM won't typically be able to "unwedge" the process.

To deal with such cases, there exist a special signal, SIGQUIT, which has a well-known number assigned to it, "9". Sending a process this signal merely makes the OS forcibly nuke the process without it having any chance to intervene. That's why you most probably saw that kill -9 $pid encantation in some docs.

Other options

There are other options, of course.

First, there exist "user-friendly" programs such as htop which present you with a searcheable list of running processes and allow you to send any of them a sgnal of choice.

Graphical desktop environments—such as GNOME, XFCE, KDE and others—usually provide a GUI app to do the same.

Second, there exist more "hacky" ways to deal with misbehaving processes for the cases where those "task managers" are unavailable or do not fit the bill for some reason. Here are some of them in no particular order:

• The xkill utility (on Debian and its derivative it's in the x11-utils package), when run, shows you a diagonal cross-shaped cursor with which you ought to select any window by cicking on it, and xkill will forcibly disconnect the process which owns that window from the X server (the program which renders all your GUI).

  The effect of this action differs between processes, but if you xkill a terminal window it will send the SIGHUP signal to the processes it manages, and this usually makes them quit.

• The pkill utility (on Debian and its derivative it's in the procps package) can be used to send a signal to a set of processes whose name matches a certain string.

  So, if you want to kill an srm process you know is running on your system, you can run

   $ pkill -9 srm
  

to bring down all the processes named srm running on the system.

Answer 2

The real answer is here

TL;DR with modern disks (and that includes anything that can hold a 7GB file), you don't really need to be that paranoid.

Since you only need to over write your file with zeros:

shred -n 0 -z trashed.dat

• where -n 0 means 0 passes with random data (without that you get the default 3 passes with random data, but that's still overkill)
• -z one final pass with zeroes (the only one needed)

Given this, to efficiently finish your secure erase:

1. stop the current command
2. run the shred command above

(bracing for sudden kharma drop...)