Pause Linux Process with SIGSTOP / SIGCONT

I recently had to back up 25 TB of data on a NAS to a Synology Diskstation connected with a single Gigabit link. The backup was done using Rsnapshot (rsync with snapshot support) but the problem was that it took 5 days of copying 24/7 to move 25 TB of data through a gigabit interface. During the day the backup couldn’t run because the NAS would become too slow to work with.

I didn’t want to stop and restart rsync every day so I had to pause it somehow. Luckily, the Linux “kill” command has more signals than just killing a process. It can also pause and resume processes. By default when you use the kill command, it will use the TERM signal which will terminate your process. Besides SIGTERM, kill also supports the following two signals:

• SIGSTOP
• SIGCONT

When you use SIGSTOP to a process, it will pause the process. It will not resume automatically unless you send a SIGCONT signal to it. This is great because it allows you to pause a process without terminating it.

I used this to pause my rsync backup at 8 AM in the morning and to resume it at 6 PM (office hours) so the backup wouldn’t bother people working during the day.

In this lesson, I’ll show you how you can pause and resume rsync, but of course, you can do this for any process.

First, we’ll have to check the PID (process ID) of rsync, you can use top or ps for this.

# top
Mem: 1942340K used, 103944K free, 0K shrd, 140292K buff, 1583880K cached
CPU: 26.8% usr 19.5% sys  0.0% nic 53.6% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 2.49 2.67 2.47 4/180 32346
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
16102 16102 root     R    43676  2.1 21.9 /opt/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /var/share /backup/

As you can see above the PID is 16102, and rsync is currently running. CPU usage is about 21 percent. You can also use ps:

# ps | grep rsync
  365 root      2544 S    grep rsync
16102 root     39256 R    /opt/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /var/share /backup/

You’ll find the same information as with top. Now let’s pause rsync:

# kill -s STOP 16102

This will freeze the process, and we can confirm this by looking at top or ps:

# top
Mem: 1942340K used, 103944K free, 0K shrd, 140292K buff, 1583880K cached
CPU: 26.8% usr 19.5% sys  0.0% nic 53.6% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 2.49 2.67 2.47 4/180 32346
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
16102 16102 root     T    43676  2.1 0.0 /opt/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /var/share /backup/

# ps | grep rsync
  365 root      2544 S    grep rsync
16102 root     39256 T    /opt/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /var/share /backup/

The “T” means the process has been stopped, and you can see that the CPU load has dropped to 0 percent. Let’s start the process again:

# kill -s CONT 16102

And you’ll see that everything is back to normal. Rsync didn’t have a clue what had just happened:

# top
Mem: 1942340K used, 103944K free, 0K shrd, 140292K buff, 1583880K cached
CPU: 26.8% usr 19.5% sys  0.0% nic 53.6% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 2.49 2.67 2.47 4/180 32346
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
16102 16102 root     R    43676  2.1 21.9 /opt/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /var/share /backup/

# ps | grep rsync
  365 root      2544 S    grep rsync
16102 root     39256 R    /opt/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /var/share /backup/

This is a cleaner method than killing the process and restarting it every time…

I hope this has been useful to you. If you have any questions feel free to leave a comment!