It's such a long-standing and persistent bug that the default advice I give nowadays to people complaining about their ubuntu "got stuck again" is to run "sudo killall -9 find".
That's really a shame:
- it's not some random IO spike coming from nowhere
- it's not 3rd-party, it's in default install
- it's reproducible
Yet, we still don't even have workaround, let alone proper policing IO of all the background tasks shipped in default ubuntu install.
Hopefully migration to systemd timer units would help tackling it.
In my case ( see https:/ /bugs.launchpad .net/ubuntu/ +source/ linux/+ bug/1460985 ) the culprit generating huge I/O throughput was in /etc/cron. daily/man- db
It's such a long-standing and persistent bug that the default advice I give nowadays to people complaining about their ubuntu "got stuck again" is to run "sudo killall -9 find".
That's really a shame:
- it's not some random IO spike coming from nowhere
- it's not 3rd-party, it's in default install
- it's reproducible
Yet, we still don't even have workaround, let alone proper policing IO of all the background tasks shipped in default ubuntu install.
Hopefully migration to systemd timer units would help tackling it.