/tmp/swap is causing my CPU busy (fwd)

[Ian Smith]

Der .. forgot to cc the list ..

---------- Forwarded message ----------
Date: Tue, 10 Jan 2017 16:23:18 +1100 (EST)
From: Ian Smith <smithi at nimnet.asn.au>
To: Bill Yuan <bycn82 at gmail.com>
Cc: Warren Block <wblock at wonkity.com>
Subject: Re: /tmp/swap is causing my CPU busy

Hi Bill, Warren.

Excuse the lack of threading .. I won't get your messages till this 
evening so I'm manually quoting copied from the archive ..

Firstly, what Warren said .. plus a few extra notes ..

 > #top

The first line would have indicated uptime.  Have you rebooted since?

 > 52 processes:  1 running, 50 sleeping, 1 zombie
 > CPU:  3.5% user,  0.0% nice,  0.6% system,  0.0% interrupt, 95.9% idle
 > Mem: 53M Active, 997M Inact, 133M Wired, 44M Buf, 791M Free
 > Swap: 2100M Total, 2100M Free

Looks like 2GiB RAM and 4 CPUs, right?

The zombie process may or may not be significant - what is it?

 >  PID USERNAME       THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
 > 25592 root            10  25    0   778M  9272K uwait   3   0:38  19.02% .swap
 > 25599 root             1  20    0  7416K  2596K CPU0    0   0:00   0.11% top

Note size of .swap here is 778M, most of the 997M inactive, but it's 
only 9MiB resident.  Also it's consumed 38 seconds of CPU time and is 
19% busy (on 1 CPU) so /4 ~= 4.75% of total (if 4 CPUs), matching 96% 
idle reasonably well - ie, apparently not much else is busy, going on 
the little you've shown.

I couldn't find 'uwait' in top(1) or ps(1), but have seen it before.

 > #ps -axd | grep swap
 > 25481  0  S+       0:00.00 | |   `-- grep swap
 > 22927  -  Ss     172:10.74 |-- /tmp/.swap

Presumably this ps was earlier than that top .. note /tmp/.swap here had 
been running for 172 minutes! CPU time, with a lower PID than the one in 
top, so it's restarted itself, or you killed it or rebooted and it's 
come back?

Also note that it has 10 threads.  'top -SHCP' will reveal more.

I'm with Warren .. this looks nasty on the face of it.  If you haven't 
already deleted it, I'd copy it to somewhere safe (a noexec mount? or a 
memstick perhaps) for later forensics, before you do.

If not obvious where it came from, strings(1) may give you useful unique 
string/s that you can search the whole filesystem for with find(1), eg: 
'find / -type f -exec grep SOME_STRING {} + -ls'

HTH, Ian