How can tasks "refuse to freeze" on suspend?

Question

Yesterday, when closing my laptop, it did not go into standby mode immediately. According to the logs, it was trying to, but a tasks refused to freeze:

Freezing of tasks failed after 20.005 seconds (1 tasks refusing to freeze, wq_busy=0):

This went on for a few hours until the system actually suspended. The syslog was full of messages like in this question, because systemd was trying again and again.

How can this happen? Why can't the scheduler just stop scheduling that application? and then it's effectively frozen? I read that there are multiple STOP commands, one of them asking nicely and one of them forcing freeze. Why did systemd not use this or why did this not work here?

Answer 1

Task freezing is documented in detail in the kernel documentation.

User-space processes can’t refuse to freeze; they do get frozen, but the signalling between the kernel and processes is handled automatically by the signal-handling code (freezing uses a fake signal).

If you’re seeing “tasks refusing to freeze” messages, that means that a kernel thread is refusing to freeze, usually because it’s doing something which can’t be checkpointed. However having to wait several hours for the kernel to suspend isn’t normal; the stack traces in the log messages would help to get some idea of what’s going wrong.