20

In my example, I am running a command that takes very long to be executed (several hours).

I don't really remember if I entered make or make -j4.

Of course I could stop it and press up key or check history to know it, but that would stop the process and I don't want that to happen (in case it is already doing make -j4).

Is there any way to know which command is being executed without stopping the process?

muru
  • 207,970
Daniel Viaño
  • 339

4 Answers4

33

If you want to see the full command line for every instance of make that is running on your computer, open a new terminal and try:

pgrep -a make

pgrep is a program that searches through all processes on your computer. In this case, it is looking for programs named make. The option -a tells pgrep to list both the process ID and the full command line for each matching process. (Without -a, it would just return the process ID.) For more information on pgrep's many options, see man pgrep.

John1024
  • 13,957
  • 7
    This is useful for simple cases like the one in the question. However if the command involved pipelines, loops, sequences of commands, internal commands, or variable expansion what you'd find with pgrep would look different from the command which was typed on the command line. – kasperd Dec 05 '18 at 12:50
28

While the terminal window is active you can pause (suspend) the process by pressing Ctrl+Z. You can then push the job in the background by typing bg (your job will now continue in the background and you can at the same time work on the command line; this is equivalent to starting a job with & at the end of the command line). Then use cursor-arrows (up and down) to see which command you used. If you want (but this is not necessary) you can then get your job to the foreground by typing fg.

Kulfy
  • 18,163
Stefan
  • 418
  • 7
    This works with some commands but not all. For example if you typed a loop like for X in {1..1000} ; do sleep $X ; done then the loop would be interrupted and remaining iterations would not happen. – kasperd Dec 05 '18 at 12:46
  • 11
    @kasperd Yes, quite annoying if you ask me, but I discovered a cool workaround for that issue. Surround a complicated command like that in parenthesis so it's a subshell. Then Ctrl-Z will suspend the whole subshell and resume correctly. – penguin359 Dec 05 '18 at 20:26
  • @kasperd Not in bash, but they do in zsh. – JoL Dec 05 '18 at 22:08
  • 4
    No need to put the job into the background: it’s sufficient to suspend it, check the history (or jobs, as shown in @ichabod’s answer), and then resuming it via fg. – Konrad Rudolph Dec 06 '18 at 14:22
10

I do something like Stefan: ^Z to pause the job, and then I run jobs. If you have multiple processes running, you may have to sort out which job was the one you paused, but this generally will give the command line. Then run fg to continue execution.

ichabod
  • 211
1

A good way to see this dynamically is to run top, and this tells you overall system state and the running processes on the system.

Doing a 'ps ux' shows your processes along with pid and other info, you can use skill to kill some of them off if you desire, man page for that is a good resource, and doing a skill or kill -9 gets sticky processes hung in device waits etc. You can also send other signals to processes such as -hup, gets daemons restarted etc.

Top is nice since it shows you process size, elapsed time, and current cpu states and that of memory and swap.

I often do a $make >& make.out& and then less or tail -f on the make.out log file. Since now make is detached as a process from my shell session.