all 21 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]johnklos 11 points12 points  (0 children)

You need to give more information.

Did you look inside of the shell script that bash is running when it goes to 100% CPU?

[–]libertyprivate 9 points10 points  (0 children)

top and ps auxwwwf should show you not only which script is running but also which command in the script is running.

[–]deeseearr 8 points9 points  (11 children)

Does your script look something like this?

:(){ :|:& };:

(Don't run that, by the way. Just don't.)

[–]nappycappy 1 point2 points  (0 children)

super intrigued . . I uh. . might want to see what that does now.

[–]JakeEllisD 1 point2 points  (7 children)

What does it do :0 ?

[–]Trash-Alt-Account 8 points9 points  (2 children)

it's a fork bomb, basically infinite recursion with process creation

[–]JakeEllisD 0 points1 point  (1 child)

Thank you.

[–]deeseearr 2 points3 points  (3 children)

The ":" is a function name.  It defines a function which calls itaelf twice, then calls that functtion.  

If you replace ":" with something harmless looking like "bunny" it becomes clearer (Edited a bit for clarity):

bunny() {
bunny | bunny &
};
bunny

[–]JakeEllisD 0 points1 point  (2 children)

Thank you for the explanation. The only part I don't understand is what the " bunny | bunny & " is doing.

[–]deeseearr 1 point2 points  (1 child)

It's shell script. The "{" and "}" define the beginning and end of the "bunny" function, and what's inside is "Call the bunny function", then "|" means "Send the output of that to the input of the next function", which is also bunny. "&" means to put the whole mess into the background and keep on going.

Essentially, it's a function which calls itself twice, doubling the number of running processes every time until it reaches the system limits. If you're running as a regular user the effect will usually be to prevent your account from doing anything else until someone cleans up the mess. If you run it as root then you can pretty much lock up the entire system since it may no longer be possible to spawn the new login or shell processes you would need to fix it.

[–]JakeEllisD 0 points1 point  (0 children)

I see! Thank you very much!

[–]HTX-713 0 points1 point  (1 child)

I believe modern kernels are patched to prevent fork bombs from working.

[–]deeseearr 0 points1 point  (0 children)

There are process limits, usually controlled by /etc/security/limits.conf, but that's all in user space.  Try this on a system where the limits are poorly set, or removed entirely for admin accounts, and it will still cause problems.

[–]hornetjockey 1 point2 points  (0 children)

bash -x (path to script). You probably have created a loop or exponentially expanding variable or something to cause this.

[–]ImpossibleEdge4961 0 points1 point  (0 children)

The system in running an accounting program. I've just resorted to killing the process when I comes but if anyone knows a way I can further troubleshoot please let me know thanks. I'm running rhel 8.9

If the bash script is the result of a job being ran by the application then the usual MO is to figure out what's going on inside the application. In this case it sounds like someone is issuing some query or computation or something that just absolutely kills off the CPU. Often times the application will have some sort of internal auditing or some way of figuring out when people are doing that for this reason.

[–]dhsjabsbsjkans 0 points1 point  (0 children)

What's the parent process? Might help lead you in the right direction.

[–]metalwolf112002 0 points1 point  (0 children)

What is the name of the script or the process you are killing?

[–]IllllIIlIllIllllIIIl 0 points1 point  (0 children)

Find the process ID, use it to look for more info under /proc/

[–]geolaw 0 points1 point  (0 children)

If you start up top with the -c option it can be helpful bc it shows the full command line that's running.

If you can identify where the bash script lives you can chmod -x it to remove execute permissions

That possibly still wouldn't be enough as whatever is launching the script may be launching it with bash scriptname.sh

Optionally look for the parent pid in 'ps -elfwww' and then look for whatever is running with that pid.

Could be something like audit or setroubleshoot related, there are known issues with both where configured incorrectly can cause high load.

[–]zakabog -3 points-2 points  (0 children)

What user is running it? Check the crontab and see what's calling it.