Is cancelling a task really killing it? I'm not sure anymore

[cwaazywabbit]

I have got a call today regarding the hogged network and found out that my 6 gobuster instances were chocking the network. Because they asked nicely I went ahead and ./celerystalk cancel <id>d all those instances but.. something still feels off.. every now and then I look at ./celerystalk query breif to find out that a new gobuster instance is running again, which is kind of strage because what I am seeing, is that only 3 nikto-tasks are left, while the others either finished or cancelled.

Submitted: 58 | Queued: 0 | Running: 3 | Completed: 47  | Cancelled: 8  | Paused: 0

and here is it again while I am writing this, 2 nikto-tasks have finished and instead two gobuster-tasks are back there, those which I remember cancelling!

and just to confirm it, here is a snapshot of the latest cancelled tasks confirming my suspecious!

and just right now I have this

but gobuster still appears in the processes

even nethogs confirms it

I am not sure anymore!

[sethsec]

Cancel really just sends a SIGTERM to the process via the kill command politely: https://en.wikipedia.org/wiki/Kill_(command).

Reference: https://github.com/sethsec/celerystalk/blob/master/lib/cancel.py#L71

There are definitely times where SIGTERM is not enough to kill the process and you have to send a SIGKILL (kill -9), but I don't have that coded in right now.

It was a long time ago but i think I didnt want to just do a SIGKILL right away was that i would potentially lose logs of partially run commands.

That said, i think it seems like a good idea to:

1. First try the sigterm
2. Check to see if the pid is still running. If it is, then send the sigkill
3. Check to see if the pid is running, if it is (i'm not sure why it would still be after a sigkill), don't switch the task to cancelled, but somehow notify the user at the command line that we could not kill the procces.

sound resonable?

[cwaazywabbit]

Sounds perfect.