3

I'm looking for a way to transparently freeze (pause) a process and then unfreeze it later. This is possible with SIGSTOP, but SIGSTOP causes the parent to be notified (by returning from waitpid), which e.g. causes bash to put interactive processes into the background (the problems with that approach are described in more detail in this link).

The cgroup subsystem has a way to accomplish this by writing to files in /sys/fs/cgroup/freezer/, but that only applies at the cgroup level – that is, you can only freeze an entire group of processes/threads at a time. I suppose one could get around this by arranging to place each process in its own cgroup, but that seems like a fair bit of hassle, and possibly dangerous since systemd et al. are already using cgroups for their own purposes.

I'm pretty close to just writing a kernel module that exposes the underlying freeze_task API to userspace, but I'd really like to avoid doing that if possible!

  • Why not just set up your own cgroup? – Michael Hampton Aug 14 '16 at 18:05
  • I need to be able to do this for arbitrary processes on the system, not just ones that I've started by hand. As far as I know each process can only be in one cgroup at a time? – Brendan Dolan-Gavitt Aug 14 '16 at 18:06
  • I'd like to see an answer to this question as well. But, are you saying that STOP/CONT aren't working in your situation? Because they should work the bulk of the time just as other signals do. I read your link, good explanation. – Ryan Babchishin Aug 14 '16 at 18:08
  • They work (as in they stop and (sometimes) continue the process) but have undesirable side effects – I just want to pause and unpause a process without affecting anything else. See superuser.com/questions/746350/… for another example of what can go wrong with STOP/CONT. – Brendan Dolan-Gavitt Aug 14 '16 at 18:10
  • @BrendanDolan-Gavitt What problem are you trying to solve by freezing processes? This can cause no end of problems if the process holds locks. – BillThor Aug 14 '16 at 19:56
4

I was able to freeze and thaw a single process (xeyes) rather easily using these directions: https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt

I know it's the same document that you linked to, but I don't see an issue with doing it this way. You could easily write a script/program to automate this all for you and freeze individual processes as desired.

On my Ubuntu 16.04 system, /sys/fs/cgroup/freezer already existed so I skipped that part.

* Examples of usage :

   # mkdir /sys/fs/cgroup/freezer    
   # mount -t cgroup -ofreezer freezer /sys/fs/cgroup/freezer    
   # mkdir /sys/fs/cgroup/freezer/0   
   # echo $some_pid > /sys/fs/cgroup/freezer/0/tasks

to get status of the freezer subsystem :

   # cat /sys/fs/cgroup/freezer/0/freezer.state    THAWED

to freeze all tasks in the container :

   # echo FROZEN > /sys/fs/cgroup/freezer/0/freezer.state    
   # cat /sys/fs/cgroup/freezer/0/freezer.state    FREEZING    
   # cat /sys/fs/cgroup/freezer/0/freezer.state    FROZEN

to unfreeze all tasks in the container :

   # echo THAWED > /sys/fs/cgroup/freezer/0/freezer.state    
   # cat /sys/fs/cgroup/freezer/0/freezer.state    THAWED

I have no idea how to clean up after. I couldn't delete the 0 directory. But I'm sure there's a way.

Is this good enough or is there something else you required?

  • 1
    A process can only be in one cgroup (per resource subsystem) at a time. So placing it into the "0" cgroup will remove it from whatever group it was already a part of, which could interfere with whatever systemd is doing with its cgroups (all my processes seem to be part of systemd per-session cgroups already). But maybe it would be good enough to save the current cgroup from /proc/<pid>/cgroup, move it into "0", then on thaw move it back to its original cgroup? – Brendan Dolan-Gavitt Aug 14 '16 at 19:50
  • @BrendanDolan-Gavitt I have no idea what systemd is doing with cgroups (or what business is has doing anything like that). But like you say, you can move the process back when done. cgroups were never a requirement of running Linux in the past... I doubt they are now. – Ryan Babchishin Aug 14 '16 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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