As mentioned it is almost certainly linux driver issue ... monit just triggers the problem, but the root cause is 3rd party.
Based on the stacktrace which is logged in https://bitbucket.org/tildeslash/monit/issues/317/monit-stuck-in-uninterruptible-sleep-state it seems that the blocked read() may probably come from collecting the system and process statistics via a /proc filesystem. It seems that in case of LXC it goes via a FUSE filesystem and gets stuck there. I think it should be possible to trigger the problem without involving monit, the following script collects the data from the /proc filesystem each 5 seconds similarly to monit, can you try to run it and see if it'll stuck as well? while (true); do cat /proc/meminfo /proc/stat /proc/[1-9]*/stat /proc/[1-9]*/status > /dev/null; sleep 5; done Regards, Martin > On 10 Feb 2016, at 01:37, deranjer <[email protected]> wrote: > > It actually is an LXC container it is running in, so I will assume that is > the issue. I'm running 5.9, so I will either manually update to 5.16 then > test it to see if anything has changed (since apparently 5.15 fixed some > signal handling issues) or just deal with the issue until the new version > hits the repos. > > > > -- > View this message in context: > http://nongnu.13855.n7.nabble.com/Unable-to-stop-monit-tp208452p208461.html > Sent from the monit-general mailing list archive at Nabble.com. > > -- > To unsubscribe: > https://lists.nongnu.org/mailman/listinfo/monit-general -- To unsubscribe: https://lists.nongnu.org/mailman/listinfo/monit-general
