How to kill a process if it keeps changing its PID

Hi,

I am new to Linux and I just want to ask question on how can I effectively kill a process that keeps changing its PID after killing it.

Here’s what I did:

✗ ps aux | grep jsextension
jeepers+   12733  0.0  0.0   6500  2492 pts/4    S+   13:25   0:00 grep --color=auto jsextension
✗ kill -9 12733
kill: sending signal to 12733 failed: No such process
✗ ps aux | grep jsextension
jeepers+   12778  0.0  0.0   6500  2500 pts/4    S+   13:25   0:00 grep --color=auto jsextension

I am developer I learned a security issue regarding this process jsextension which you can read more about here.

I have tried killing it via pkill, killall but to no avail.

I am planning to reinstall EndeavourOS if there’s no other way to kill it.

Thanks for your help.

I’m no expert here, but how about chrooting into the installation and removing the source file of jsextension?

edit:

Doesn’t look like jsextension thingy is running on your system.

jeepers+   12733  0.0  0.0   6500  2492 pts/4    S+   13:25   0:00 grep --color=auto jsextension

This line shows running command as grep --color=auto jsextension, which is the process reading output from ps -aux - the command you ran. When then command has executed, the PID no longer exists, hence you aren’t able to kill it

✗ kill -9 12733
kill: sending signal to 12733 failed: No such process

Hi, thanks for responding.

So there’s no running process with the name jsextension? and the PID that keeps changing came from grep command itself?

indeed thats what I understand.

For example, if i see my terminals, this is the output

$ ps -aux | grep alacritty
snehit      7669  0.2  1.9 708060 76648 ?        Sl   11:09   0:00 alacritty
snehit      7798  9.0  1.9 707924 76576 ?        Sl   11:14   0:00 alacritty
snehit      7801  8.0  1.9 707928 76360 ?        Sl   11:14   0:00 alacritty
snehit      7866  0.0  0.0   7540  2428 pts/0    S+   11:14   0:00 grep alacritty

I had 3 terminals (alacritty) running, and fourth one is the grep command reading output from ps -aux.

Best confirmation will be to comment at the GitHub issue link you posted and ask others what they observed if their system was infected. I’m no security expert. All I can confirm is that there is no process by jsextension that is running. But is it confirmed that its not running by a different name?

Alright, thank you @flyingcakes .

Will ask the issue thread regarding Linux machines affected by the malware.

1 Like

From the GitHub Advisory Database:

The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Source : https://github.com/advisories/GHSA-pjwm-rvh2-c87w

PS.

If I were you, I’d stop using that particular machine temporarily until I were confirmed that I’m safe from malware. If I had to use the machine anyways, I’d wipe and reinstall.

1 Like

Yes

You are just trying to kill that grep jsextension you just called but it was already closed when it printed you the result.

You can also try

killall -r

That will close every instance of the process based on its name and not directly PID. -r (regex) can help you if you do not know exactly the name of the process so you can use something like ^.*jsextension.*$ which will match any process name which contains string jsextension.

Or investigate all your processes in pstree and look for parent process that spawns jsextension and kill that (it may have completely different name).

edit:
By the way

This may be interesting for you @flyingcakes since you used ps -aux and not ps aux. From ps man page.

Note that ps -aux is distinct from ps aux. The POSIX and UNIX standards require that ps -aux print all processes owned by a user named x, as well as printing all processes that would be selected by the -a option. If the user named x does not exist, this ps may interpret the command as ps aux instead and print a warning. This behavior is intended to aid in transitioning old scripts and habits. It is fragile, subject to change, and thus should not be relied upon.

1 Like

Thanks! :slight_smile:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.