Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
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 at 15:49
First idea: logrotate – Jakuje Jan 24 at 18:41
@terdon The thumbnail should be clickable now. – Sparhawk Jan 25 at 5:34
@Sparhawk That doesn't help for copy-paste and searching. – kasperd Jan 25 at 10:40
@kasperd I agree (it also doesn't make it "lighter"), but at least we can read it now! – Sparhawk Jan 25 at 10:43
up vote 24 down vote accepted

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.


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.


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.

share|improve this answer
+1 for the wrapper idea; capture the parent process tree with $$ – Jeff Schaller Jan 24 at 14:46
Thanks, I will give this a shot the next time the "issue" appears again, I'll report back. – ultio Jan 25 at 15:04
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. – ultio Feb 2 at 23:10

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.

share|improve this answer

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
    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
    terdon   25266 25266 /bin/bash /home/terdon/scripts/a.sh
  4. Alternatively, investigate the process tree:

    $ pstree -p 25266
  5. Find out what directory this is being run from (Linux):

    $ readlink -f /proc/25267/cwd

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.

share|improve this answer

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?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.