5

For a while now, I have had the problem that a gzip process randomly starts on my Kubuntu system, uses up quite a bit of resources and causes my notebook fan to go crazy. The process shows up as gzip -c --rsyncable --best in htop and runs for quite a long time. I have no clue what is causing this, the system is a Kubuntu 14.04 and has no backup plan setup or anything like that. Any idea how I can figure out what is causing this the next time the process appears? I have done a bit of googling already but could not figure it out. I saw some suggestions with the ps command but grepping all lines there did not really point to anything.

gzip -c --rsyncable --best

Sparhawk
  • 19,941
TiEul
  • 161
  • 16
    Please don't post screenshots of text. Just paste the text directly into your answer and use the formatting tools to make it clear. That image is tiny and hard to read and makes the post heavier for no reason. – terdon Jan 24 '16 at 15:49
  • 5
    First idea: logrotate – Jakuje Jan 24 '16 at 18:41
  • @terdon The thumbnail should be clickable now. – Sparhawk Jan 25 '16 at 05:34
  • 1
    @Sparhawk That doesn't help for copy-paste and searching. – kasperd Jan 25 '16 at 10:40
  • @kasperd I agree (it also doesn't make it "lighter"), but at least we can read it now! – Sparhawk Jan 25 '16 at 10:43
  • @terdon All important info was supplied in my written text, I only added it as an extra in case I missed something. I admit though that I did not know how to make it clickable and I figured people would just right click -> view image. – TiEul Jan 25 '16 at 15:03
  • @ultio no big deal, I'm just letting you know since you're new here. Next time, just copy/paste directly and format it to look like code. – terdon Jan 25 '16 at 15:20

4 Answers4

25

Process tree

While the process is running try to use ps with the f option to see the process hierarchy:

ps axuf

Then you should get a tree of processes, meaning you should see what the parent process of the gzip is.

If gzip is a direct descendant of init then probably its parent has exited already, as it's very unlikely that init would create the gzip process.

Crontabs

Additionally you should check your crontabs to see whether there's anything creating it. Do sudo crontab -l -u <user> where user is the user of the gzip process you're seeing (in your case that seems to be root).

If you have any other users on that system which might have done stuff like setting up background services, then check their crontabs too. The fact that gzip runs as root doesn't guarantee that the original process that triggered the gzip was running as root as well. You can see a list of all existing crontabs by doing sudo ls /var/spool/cron/crontabs.

Logs

Check all the systems logs you have, looking for suspicious entries at the time the process is created. I'm not sure whether Kubuntu names its log files differently, but in standard Ubuntu you should at least check /var/log/syslog.

Last choice: a gzip wrapper

If none of these lead to any result you could rename your gzip binary and put a little wrapper in place which launches gzip with the passed parameters but also captures the system's state at that moment.

Lightness Races in Orbit
  • 347
replay
  • 8,553
  • 1
  • 27
  • 31
  • 11
    +1 for the wrapper idea; capture the parent process tree with $$ – Jeff Schaller Jan 24 '16 at 14:46
  • Thanks, I will give this a shot the next time the "issue" appears again, I'll report back. – TiEul Jan 25 '16 at 15:04
  • 1
    Thanks, I figured it out with your help. The process was actually started by one of the Linux containers (LXC) on my system, which explains why I could not find it initially, as it was managed from within the LXC and not from my host OS. – TiEul Feb 02 '16 at 23:10
5

You should probably focus on what files its working with:

lsof -c gzip

...should give you a pretty good idea and is exactly what htop would do for you if you only pressed l after highlighting the listing in the image in your question. Besides that, htop will also present you with a process tree if you request it by pressing your F5 key, and so you would directly see the process's parentage, if any.

On linux systems:

ps -Fwwp"$((gzip_ppid=$(ps -oppid= -Cgzip)))"
fuser -vau "/proc/$gzip_ppid/fd/"*

...should print a good deal of information about gzip's parent process and its used files as well as other processes also using them.

mikeserv
  • 58,310
1

pstree provides a nicely formatted output displaying what spawned what (assuming the parent does not die immediately after spawning the gzip command)

Also check out Is there an easy way to log all commands executed, including command line arguments?

Community
  • 1
Sandeep
  • 11
1

Here are a few tricks that can help you figure out what's going on:

  1. Get the offending process's PID:

    $ pgrep -a gzip 
25267 gzip -c --best file

    On my system (where I've launched a big gzip job), that returns the single PID: 25267. You might have more than one so, make sure to choose the right one. The -a flag tells pgrep to print the full command line, that way you can see what exactly is being run.

  2. Get the PID of the process that launched it, the parent PID or PPID and the user responsible:

    $  ps -p 25267 -o user -o pid -o pgid -o args
USER       PID  PGID COMMAND
terdon   25267 25266 gzip -c --best file

    Now we know that the gzip was launched by terdon via a process whose PID is 25266.

  3. Find out what the parent process is:

    $ ps -p 25266 -o user -o pid -o pgid -o args
USER       PID  PGID COMMAND
terdon   25266 25266 /bin/bash /home/terdon/scripts/a.sh

  4. Alternatively, investigate the process tree:

    $ pstree -p 25266
a.sh(25266)───gzip(25267)

  5. Find out what directory this is being run from (Linux):

    $ readlink -f /proc/25267/cwd
/home/terdon/foo

So, in my case, it was launched by a shell script, /home/terdon/scripts/a.sh, and is running in /home/terdon/foo. Obviously, all of these details will be different on your system, but these commands should help you figure out what's going on.

terdon
  • 242,166