Shulou(Shulou.com)06/03 Report--

Solve the problem

The first thing that came to mind at that time was the virus. No matter how much it was, the first step was to find those processes that consumed cpu to kill. Use the top command to see which processes consume cpu. It is clear at a glance that it is all caused by bzip2.

The process of killing the process found a problem, that is, these processes were killed and then reappeared after a while. This kind of phenomenon, I know must find their father process, catch the thief first capture the king.

# ps-lA | grep bzip20 R 0 1965 1964 44 800-3435 -? 00:01:43 bzip20 S 0 1981 1980 33 800-3435 pipe_w? 00:00:56 bzip20 R 0 1997 1996 30 800-3435 -? 00:00:31 bzip20 R 0 2013 2012 27 800-3435 -? 00:00:07 bzip20 R 0 2024 2023 15 800 0-3435 -? 00:00:00 bzip2

But I found that their ppid is not the same, which makes me very confused. I'm going to take a look at the process tree.

Pstree-up

At this time, I knew that there was something wrong with my timing script. Then I need to do the following things:

Turn off the crond service

Crontab-e get rid of weekly.sh

Kill the processes that consume cpu

# close [root@iz8vb626ci0aehwsivxaydz ~] # kill 1622 [root@iz8vb626ci0aehwsivxaydz ~] # systemctl status crond ● crond.service-Command Scheduler Loaded: loaded (/ usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2019-11-12 10:44:32 CST 10s ago Main PID: 1622 (code=exited, status=0/SUCCESS) # modify crontab-e # to kill consumptive cpu process. The following command was executed several times before all consumed cpu processes were killed ps-lA | grep bzip2 | awk'{print $4}'| xargs-n 10 kill-9

The cause and thinking of the problem

At first, I thought there was something wrong with my shell script, which was caused by an endless loop. But when you look at the script, there is no problem, and there is no endless loop. For a moment, I couldn't think of my sister.

#! / bin/bash# Weekly backup script export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/binexport backdir=/backup/weekly # backup directory [- z "$backdir"] | | mkdir-p $backdir dirs= (/ etc / home / root/ usr/ var/spool/cron / var/spool/at) # directory to be backed up for dir in ${dirs [@]} do if [!-d $dir] Then continue fi cd $backdir tar-jcpf $(basename $dir) _ $(date +% Y%m%d). Tar.bz2 $dirdone # Delete files with mtime greater than 30 days find $backdir-mtime + 30-name * .tar.bz2-exec rm-f {}\

After a long time, I finally found the reason. It turned out that there was something wrong with my own scheduled task writing.

* 3 * * 1 / root/bin/weekly.sh 1 > / dev/null 2 > & 1

My original idea was to execute the backup script every Monday at 3: 00 a. M., but the result is that it is executed every minute at 3: 00 a. M. every Monday. The correct way to write it is as follows:

# execute the script 1 3 * * 1 / root/bin/weekly.sh 1 > / dev/null 2 > & 1 every Monday at 03:01

The above is the details of a server CPU full event, please pay attention to other related articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.