Identifying suspicious bash process (high cpu and ram usage)

alextim · 2023-05-18 12:37:28

Hello,

A couple of days ago I noticed a bash process in htop with relatively high, fluctuating cpu and ram usage. Started closing windows one by one to try pinpointing it, when I closed Firefox that also killed the process.

I then went online for answers, found this post and the second and third time I noticed it I tried some of the suggestions but I don't know how to interpret the output (posted below).

For reference, on the second and third sightings it had PID 6774 and 13054 respectively. Each time closing Firefox killed it. I noticed this over the course of two days.
htop2
htop1

It doesn't always start when I start Firefox. After login I filtered "bash" in htop and marked out the processes I could positively identify, then started Firefox but no new bash process started (at least not while I was looking) during a day of normal use.

When I launch Firefox (or any other application) with dmenu, this launches a bash process. As far as I can tell this is different than the rogue process I'm asking about, since it's `ps` output is:

❯❯ ps 5575
    PID TTY      STAT   TIME COMMAND
   5575 ?        S      0:00 /bin/bash

The rogue process's output below. That one also has the same VIRT, RES and SHR as Firefox, while the dmenu bash process doesn't.

Other info. that may or may not be relevant:
- OS: archlinux-2023.04.01-x86_64
- dwm window manager, no other desktop environment
- Login with startx, no other display manager
- Firefox launched with dmenu

❯❯ ps 13054

    PID TTY      STAT   TIME COMMAND
  13054 ?        Sl     1:32 /usr/lib/firefox/firefox

❯❯ ps -p 6774 -o pid,user,tty,comm,args

    PID USER     TT       COMMAND         COMMAND
   6774 tim      ?        firefox         /usr/lib/firefox/firefox

❯❯ pstree

systemd─┬─NetworkManager───3*[{NetworkManager}]
        ├─bash─┬─konsole─┬─bash───pstree13054
        │      │         └─3*[{konsole}]
        │      └─slstatus
        ├─bash───firefox─┬─Isolated Web Co───13*[{Isolated Web Co}]
        │                ├─3*[Isolated Web Co───14*[{Isolated Web Co}]]
        │                ├─Privileged Cont───13*[{Privileged Cont}]
        │                ├─RDD Process───3*[{RDD Process}]
        │                ├─Socket Process───4*[{Socket Process}]
        │                ├─Utility Process───3*[{Utility Process}]
        │                ├─2*[Web Content───12*[{Web Content}]]
        │                ├─Web Content───13*[{Web Content}]
        │                ├─WebExtensions───14*[{WebExtensions}]
        │                └─96*[{firefox}]
        ├─dbus-daemon
        ├─login───bash───startx───xinit─┬─Xorg─┬─xf86-video-inte
        │                               │      └─2*[{Xorg}]
        │                               └─dwm─┬─alacritty─┬─bash───ranger───mpv───9*[{mpv}]
        │                                     │           └─8*[{alacritty}]
        │                                     ├─alacritty─┬─bash───htop
        │                                     │           └─8*[{alacritty}]
        │                                     ├─2*[alacritty─┬─ranger]
        │                                     │              └─8*[{alacritty}]]
        │                                     ├─alacritty─┬─bash
        │                                     │           └─8*[{alacritty}]
        │                                     └─konsole─┬─bash
        │                                               └─3*[{konsole}]
        ├─mpv───15*[{mpv}]
        ├─polkitd───3*[{polkitd}]
        ├─rtkit-daemon───2*[{rtkit-daemon}]
        ├─sublime_text─┬─plugin_host-3.3───2*[{plugin_host-3.3}]
        │              ├─plugin_host-3.8───2*[{plugin_host-3.8}]
        │              └─15*[{sublime_text}]
        ├─sxiv
        ├─systemd─┬─(sd-pam)
        │         ├─at-spi-bus-laun─┬─dbus-daemon
        │         │                 └─4*[{at-spi-bus-laun}]
        │         ├─at-spi2-registr───3*[{at-spi2-registr}]
        │         ├─dbus-daemon
        │         ├─dconf-service───3*[{dconf-service}]
        │         ├─evolution-addre───6*[{evolution-addre}]
        │         ├─evolution-calen───7*[{evolution-calen}]
        │         ├─evolution-sourc───4*[{evolution-sourc}]
        │         ├─gvfs-udisks2-vo───4*[{gvfs-udisks2-vo}]
        │         ├─gvfsd─┬─gvfsd-dnssd───3*[{gvfsd-dnssd}]
        │         │       ├─gvfsd-network───4*[{gvfsd-network}]
        │         │       ├─gvfsd-trash───3*[{gvfsd-trash}]
        │         │       └─3*[{gvfsd}]
        │         ├─gvfsd-fuse───6*[{gvfsd-fuse}]
        │         ├─gvfsd-metadata───3*[{gvfsd-metadata}]
        │         └─pulseaudio─┬─gsettings-helpe───4*[{gsettings-helpe}]
        │                      └─2*[{pulseaudio}]
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-udevd
        └─udisksd───5*[{udisksd}]

Amy help would be greatly appreciated.

Don't know if it's relevand but here's my .xinitrc

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then







    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then







    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi


# My aditons

xrandr --output LVDS1 --mode 1366x768 --output VGA1 --mode 1920x1080 --right-of LVDS1 &
[[ -f ~/Xmodmap ]] && xmodmap ~/.Xmodmap &
exec dwm

Last edited by alextim (2023-05-19 15:45:44)

Trilby · 2023-05-18 12:53:17

You are keeping around a lot of live "bash" shells for no reason. A good example of this, though itself not related to this issue, is your gui session process tree showing login > bash > startx > xinit -> dwm. Most of these processes should have been replaced by exec calls. E.g., instead of using `startx`, you may want to use `exec startx`, and dwm should be launched from your xinitrc with `exec dwm`.

This same pattern follows with firefox which shows a live bash shell as it's parent. So first to test whether this condition is relevant: start firefox without dmenu and see if the problem is avoided*. I'd suspect that it will be. If it indeed is, then the fix is to adjust your dmenu_run script to properly `exec` child processes rather than keeping a live shell around for no reason.

While I can't outline the exact way this could become a problem, I would not be surprised if firefox's behavior of essentially daemonizing itself to process requests for new windows would be related. In other words, I suspect the problem might arise only when firefox is launched from your (currently somewhat broken) dmenu_run script, and then subsequently opens multiple windows and closes the original one.

*sidenote: this is not a perfect test as there are other sources of such problems that can come from the dmenu_run script related to it's handling of standard streams (stdin/stdout/stderr). But still knowing whether dmenu is relevant would greatly narrow down the scope of the problem and if it is relevant, eliminating the needless shell would be a good first step.

Last edited by Trilby (2023-05-18 13:11:08)

seth · 2023-05-18 13:36:52

https://bbs.archlinux.org/viewtopic.php … 2#p2094112

alextim · 2023-05-18 14:21:11

Trilby wrote:

You are keeping around a lot of live "bash" shells for no reason. A good example of this, though itself not related to this issue, is your gui session process tree showing login > bash > startx > xinit -> dwm. Most of these processes should have been replaced by exec calls. E.g., instead of using `startx`, you may want to use `exec startx`, and dwm should be launched from your xinitrc with `exec dwm`.
This same pattern follows with firefox which shows a live bash shell as it's parent. So first to test whether this condition is relevant: start firefox without dmenu and see if the problem is avoided*. I'd suspect that it will be. If it indeed is, then the fix is to adjust your dmenu_run script to properly `exec` child processes rather than keeping a live shell around for no reason.
While I can't outline the exact way this could become a problem, I would not be surprised if firefox's behavior of essentially daemonizing itself to process requests for new windows would be related. In other words, I suspect the problem might arise only when firefox is launched from your (currently somewhat broken) dmenu_run script, and then subsequently opens multiple windows and closes the original one.
*sidenote: this is not a perfect test as there are other sources of such problems that can come from the dmenu_run script related to it's handling of standard streams (stdin/stdout/stderr). But still knowing whether dmenu is relevant would greatly narrow down the scope of the problem and if it is relevant, eliminating the needless shell would be a good first step.

I tried some of your suggestions but am not clear on others.

I launched Firefox without dmenu, `pstree` bellow.

I did notice that launching dmenu starts a bash process (I assumed that was normal) and that said process stays open as long as Firefox, or any other application launched with dmenu, is open (though I don't think it's the suspicious process I'm trying to ID since it has a different `ps` output and never really eats any resources). I should mention that I didn't mess around with the dmenu config other than changing the highlight color and font.

When I startx I'm actually typing a bash alias `st`. Is that maybe a problem and, just so I understand, should I type `exec startx` instead? The below `pstree` is after I simply typed `startx` not the alias but I don't notice anything different in the login--bash--startx--xinit--Xorg chain

Dwm on the other hand is launched from xinitrc with 'exec dwm'.

systemd─┬─NetworkManager───3*[{NetworkManager}]
        ├─bash───slstatus
        ├─dbus-daemon
        ├─login───bash───startx───xinit─┬─Xorg─┬─xf86-video-inte
        │                               │      └─2*[{Xorg}]
        │                               └─dwm─┬─2*[alacritty─┬─htop]
        │                                     │              └─8*[{alacritty}]]
        │                                     ├─firefox─┬─Isolated Web Co───14*[{Isolated Web Co}]
        │                                     │         ├─Privileged Cont───13*[{Privileged Cont}]
        │                                     │         ├─Socket Process───4*[{Socket Process}]
        │                                     │         ├─3*[Web Content───13*[{Web Content}]]
        │                                     │         ├─WebExtensions───15*[{WebExtensions}]
        │                                     │         └─65*[{firefox}]
        │                                     └─konsole─┬─bash───pstree
        │                                               └─3*[{konsole}]
        ├─polkitd───3*[{polkitd}]
        ├─rtkit-daemon───2*[{rtkit-daemon}]
        ├─sublime_text─┬─plugin_host-3.3───2*[{plugin_host-3.3}]
        │              ├─plugin_host-3.8───2*[{plugin_host-3.8}]
        │              └─15*[{sublime_text}]
        ├─systemd─┬─(sd-pam)
        │         ├─at-spi-bus-laun─┬─dbus-daemon
        │         │                 └─4*[{at-spi-bus-laun}]
        │         ├─at-spi2-registr───3*[{at-spi2-registr}]
        │         ├─dbus-daemon
        │         ├─dconf-service───3*[{dconf-service}]
        │         ├─evolution-addre───6*[{evolution-addre}]
        │         ├─evolution-calen───7*[{evolution-calen}]
        │         ├─evolution-sourc───4*[{evolution-sourc}]
        │         ├─gvfs-udisks2-vo───4*[{gvfs-udisks2-vo}]
        │         ├─gvfsd─┬─gvfsd-dnssd───3*[{gvfsd-dnssd}]
        │         │       ├─gvfsd-network───4*[{gvfsd-network}]
        │         │       ├─gvfsd-trash───3*[{gvfsd-trash}]
        │         │       └─3*[{gvfsd}]
        │         ├─gvfsd-fuse───6*[{gvfsd-fuse}]
        │         ├─gvfsd-metadata───3*[{gvfsd-metadata}]
        │         ├─pulseaudio─┬─gsettings-helpe───4*[{gsettings-helpe}]
        │         │            └─2*[{pulseaudio}]
        │         ├─tumblerd───7*[{tumblerd}]
        │         └─xfconfd───3*[{xfconfd}]
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-udevd
        ├─udisksd───5*[{udisksd}]
        ├─upowerd───3*[{upowerd}]
        └─wpa_supplicant

alextim · 2023-05-18 14:25:16

seth wrote:

https://bbs.archlinux.org/viewtopic.php … 2#p2094112

I read most of that thread but I'm not sure how it pertains to my issue. Sorry if I missed something obvious. Firefox itself works and behaves fine, the suspicious bash process is definitely connected to it somehow but it doesn't always appear (haven't seen it in almost two days). I only ever launched Firefox with dmenu (until today when I made a custom command for it in dwm), not by clicking any external links.

I added my .xinitrc to the op if that helps in any way.

seth · 2023-05-18 14:36:48

Firefox depends its behavior on whether there's an open stdout/stderr

Trilby's suggestion is to edit /usr/bin/dmenu_run (or better: shadow it w/ a copy in /usr/local/bin and edit that) and make sure that instead of running a subshell that runs the command, the dmenu_run shell is replaced by the command itself, eg.

exec $(dmenu_path | dmenu "$@")

alextim · 2023-05-19 09:41:47

seth wrote:

Firefox depends its behavior on whether there's an open stdout/stderr
Trilby's suggestion is to edit /usr/bin/dmenu_run (or better: shadow it w/ a copy in /usr/local/bin and edit that) and make sure that instead of running a subshell that runs the command, the dmenu_run shell is replaced by the command itself, eg.
exec $(dmenu_path | dmenu "$@")

Just to clarify, I should replace

dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} &

from dmenu_run with:

exec $(dmenu_path | dmenu "$@")

?

Also, I didn't find dmenu_run in /usr/bin, only in /usr/local.bin

seth · 2023-05-19 12:41:41

For instance - you can make that script randomly complex and analyze the input to discriminate the execution.

Also, I didn't find dmenu_run in /usr/bin, only in /usr/local/bin

You're not using the dmenu package? How did you install dmenu?
Do you apply any patches?

alextim · 2023-05-19 14:46:32

I installed dmenu the same way I installed dwm:

git clone https://git.suckless.org/dmenu -> make -> sudo make clean install

I didn't patch dmenu but i did patched dwm:

autostart-20210120-cb3f58a, cursorwarp-6.3, movestack-20211115-a786211, pertag-20200914-61bb8b2, scratchpads-20200414-728d397b, statusallmons-6.2, systray-6.4, vanitygaps-6.2

As for changing the dmenu script, I'm willing to try it but, if I'm understanding you guys correctly, that would make it so that processes launched with dmenu would launch without a bash process attached. However I already wrote an independent launch command for Firefox, at Trilby's suggestion, and now it launches without said bash process.

The problem is, I don't think that the processes I mention in the op (6774 and 13054) are the bash processes resulted from the initial FF. dmenu launch. My reasoning:

When I do launch FF. with dmenu, it starts a bash process (PID 5575 in this ex.).
If I `ps` 5575 I get:

❯❯ ps 5575
    PID TTY      STAT   TIME COMMAND
   5575 ?        S      0:00 /bin/bash

while when I `ps` 13054 and 6774 (the processes in the htop screengrabs) I got:

❯❯ ps 13054

    PID TTY      STAT   TIME COMMAND
  13054 ?        Sl     1:32 /usr/lib/firefox/firefox

❯❯ ps -p 6774 -o pid,user,tty,comm,args

    PID USER     TT       COMMAND         COMMAND
   6774 tim      ?        firefox         /usr/lib/firefox/firefox

seth · 2023-05-19 14:59:35

while when I `ps` 13054 and 6774 (the processes in the htop screengrabs) I got:

But those are firefox processes?
The thread is about rogue bash processes and Trilby's suspicion was that those are due to dmenu creating a subshell to launch FF and keep that process around.

alextim · 2023-05-19 15:06:45

seth wrote:

while when I `ps` 13054 and 6774 (the processes in the htop screengrabs) I got:
But those are firefox processes?
The thread is about rogue bash processes and Trilby's suspicion was that those are due to dmenu creating a subshell to launch FF and keep that process around.

I suspect that they are since killing FF also killed the processes, the `ps` output, and the fact that they have the same VIRT, RES and SHR as FF.

seth · 2023-05-19 15:13:24

Then what does that have to do w/

while when I `ps` 13054 and 6774 (the processes in the htop screengrabs) I got:

Compare the rogue bash processes against "ps fax"

alextim · 2023-05-19 15:29:48

seth wrote:

Then what does that have to do w/
while when I `ps` 13054 and 6774 (the processes in the htop screengrabs) I got:
Compare the rogue bash processes against "ps fax"

Running `ps` was suggested in this post. I used it to differentiate between the suspicious processes and the FF dmenu launch process. I updated the op to clarify.

The rogue process isn't running at the moment. Hasn't been for two days. `ps fax` doesn't show any bash process I can't identify.

Last edited by alextim (2023-05-19 15:46:30)

Arch Linux

#1 2023-05-18 12:37:28

Identifying suspicious bash process (high cpu and ram usage)

#2 2023-05-18 12:53:17

Re: Identifying suspicious bash process (high cpu and ram usage)

#3 2023-05-18 13:36:52

Re: Identifying suspicious bash process (high cpu and ram usage)

#4 2023-05-18 14:21:11

Re: Identifying suspicious bash process (high cpu and ram usage)

#5 2023-05-18 14:25:16

Re: Identifying suspicious bash process (high cpu and ram usage)

#6 2023-05-18 14:36:48

Re: Identifying suspicious bash process (high cpu and ram usage)

#7 2023-05-19 09:41:47

Re: Identifying suspicious bash process (high cpu and ram usage)

#8 2023-05-19 12:41:41

Re: Identifying suspicious bash process (high cpu and ram usage)

#9 2023-05-19 14:46:32

Re: Identifying suspicious bash process (high cpu and ram usage)

#10 2023-05-19 14:59:35

Re: Identifying suspicious bash process (high cpu and ram usage)

#11 2023-05-19 15:06:45

Re: Identifying suspicious bash process (high cpu and ram usage)

#12 2023-05-19 15:13:24

Re: Identifying suspicious bash process (high cpu and ram usage)

#13 2023-05-19 15:29:48

Re: Identifying suspicious bash process (high cpu and ram usage)

Board footer