I'm working with some tail -f path/to/my/log/file | grep pattern& and I need to kill the process as quick as possible. With classic kill {tail PID}, tail still displays its buffer and it takes around 12 second (on my setup) to get tail completely silent.

However, it's much faster when I kill it with kill %{job id} (slightly more than a second).

How is it different to call kill {tail PID} and kill %{job id}?

Some samples :

01/09/2021 15:45:29:670:kill {tail PID}
01/09/2021 15:45:39:232: {some log}
01/09/2021 15:45:39:232: {some log}
01/09/2021 15:45:39:232: {last log line}  
takes around 10 seconds to fully shutdown

with kill %{job id} :

01/09/2021 10:56:57:793 -> (COM12<):kill %{tail job ID}
01/09/2021 10:56:58:966 -> (COM12>):[root@my_board ~]# 
takes 1 sec to fully shutdown
  • Sorry. The question is what is the difference between kill and killall? If yes, both of them just a wrapper to the kill system call. When the system is busy, poor killall may much slower than kill, because it's needed to read the running process list.
    – K-att-
    Sep 9 at 8:14
  • 1
    the jobs command returns the background jobs with their job ID like presented here
    – Maskim
    Sep 9 at 10:58
  • 1
    You can kill background jobs by specifying their job ID with kill %<job ID>. My question is : In my case, killing a job using its job ID is much faster than killing it using its PID and I'm wondering why
    – Maskim
    Sep 9 at 11:06
  • 1
    Ok, I give up. I don't know what do you exactly do. I started some tail in background, but I give up now.
    – K-att-
    Sep 9 at 12:23
  • 1
    @K-att- If you start a command in background, you will get a line like this in output from the shell (at least if you are using bash): [1] 9322. The first number, in square brackets, is the job ID of the background process, the second number is it's PID. You can kill that process using either kill PID or kill %job-ID. The OP asks why the latter is faster, which is really strange. I have never seen such behaviour.
    – raj
    Sep 9 at 12:51

When you kill the job with kill %6, you kill the tail and kill grep too.

tail -f /var/log/mintupdate.log|grep ez&
[6] 3368377

If you kill 3368377, you kill just the grep process.

3368376 pts/6    S      0:00 tail -f /var/log/mintupdate.log
3368377 pts/6    S      0:00 grep --color=auto ez

Of course it caused to kill the tail -f too....

  • This is a good observation, but it doesn’t explain why the output continues in the first case (tail’s output goes through grep, so once grep is killed there’s no more output). Sep 9 at 13:45
  • Pipe is broken, process terminate I think. Until not. I don't know why (and I don't want to strace the tail process).
    – K-att-
    Sep 9 at 13:50
  • Yes, when a pipe is broken, the next time the writer attempts to write, it is terminated (SIGPIPE). Sep 9 at 13:56
  • I don't know why continues the output, sorry ..... (I thought the problem is the time...)
    – K-att-
    Sep 9 at 14:00
  • 1
    The buffer of tail that is still displayed during ~10 seconds in my sample is still filtered by grep so I don't think grep is immediately shut down. I've tried different signals to shutdown the jobs (with ID or PID) and it does not help. It looks like even grep empties its buffer before really getting shut down
    – Maskim
    Sep 13 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.