Это меня озадачило. У меня Ubuntu 14.04, 3 дня назад (2014-20-10) он начал тормозить.
Я воспроизвел ее, открыв и затем закрыв gedit. Когда проблема активна, требуется около 2 секунд, чтобы закрыть пустой файл, в то время как без проблемы это всегда происходит мгновенно — и влияет на все остальное аналогичным образом.
top не сообщает о необычной активности при замораживании, htop то же самое, iotop то же самое.
Проблема возникает только после 30 минут безотказной работы. Могу гарантировать, что за 29 минут безотказной работы я не смог ее воспроизвести, а за 31 минуту безотказной работы я смог ее воспроизвести постоянно (используя описанный выше метод, не запуская никаких приложений, кроме терминала и htop), и мне удалось повторить это 4 или 5 раз (выключив, загрузив и подождав полчаса — что было приятно).
Проблема сохраняется даже после перезагрузки, но ее можно устранить, выключив и снова включив компьютер. Какая часть Ubuntu сохраняет состояние после перезагрузки, но не выключения?
Соответствующие журналы за этот период: syslog, auth.log и Xorg.0.log (путем проверки содержимого /var/log на предмет времени изменения в указанном диапазоне)
системный журнал:
Oct 22 17:21:36 raiden NetworkManager[1102]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Oct 22 17:39:01 raiden CRON[3284]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Oct 22 18:09:01 raiden CRON[3370]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
аутлог:
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 17:39:01 raiden CRON[3283]: pam_unix(cron:session): session closed for user root
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:09:01 raiden CRON[3369]: pam_unix(cron:session): session closed for user root
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 22 18:17:01 raiden CRON[3495]: pam_unix(cron:session): session closed for user root
Xorg.0.log: (вероятно, я просто пытаюсь включить компьютер)
[ 3466.727] (II) intel(0): switch to mode [email protected] on LVDS1 using pipe 0, position (0, 900), rotation normal, reflection none
[ 3466.880] (II) intel(0): switch to mode [email protected] on VGA1 using pipe 1, position (0, 0), rotation normal, reflection none
Ничто из этого не указывает на что-либо плохое, а последующие шаги по воспроизведению проблемы не выявили никаких изменений в журналах, так что, скорее всего, это были просто безобидные журналы.
Я предполагаю, что существует три возможных источника этой проблемы:
Установка ПО: Я установил что-то подозрительное
Я сделал:
- история | grep apt-get' - нет установок за этот период времени
- Просмотрел историю менеджера пакетов Synaptic — ничего за этот период времени.
- История центра программного обеспечения - последнее обновление было несколько недель назад (возникла проблема с зависимостями, поэтому я некоторое время не делал никаких обновлений)
- Я установил Skype для Ubuntu примерно в то же время, но нет никаких признаков того, что проблема связана со Skype (я все равно удалил его).
Работа Cron идет не так
Проверил cronjobs в crontab, /etc/cron.d /etc/cron.daily и hourly - ничего, что указывало бы на что-то, кроме задания PHP cron, которое выполняется каждые 30 минут, но если бы это был cron, то оно выполнялось бы в определенные моменты круглосуточно, а не через 30 минут после запуска.
Анализ новых процессов, запущенных между состоянием без замедления и состоянием замедления, показывает, что никаких новых процессов не запущено (первый тест показал поток kworker, но это, скорее всего, просто совпадение). Я предполагаю, что это должно означать, что либо существующий процесс вызвал его, либо что-то еще.
Вредоносное ПО
Из-за его неуловимости и таинственного 30-минутного отсутствия проблемы (30 минут кажутся выбранным человеком промежутком времени) я начал думать, что это может быть какая-то вредоносная программа, хотя это и маловероятно (не обновлялся некоторое время и имел несколько открытых портов). Поэтому запустил rkhunter (поиск руткитов), но ничего подозрительного не обнаружил.
Что еще я пробовал:
- Снятие отметок с некоторых компонентов Compiz — никаких изменений
- Перезапуск compiz - никаких изменений.
- Снял галочки со всех компонентов Compiz — никаких изменений (кроме того, что мне пришлось побороться, чтобы снова заставить компьютер работать)
- Играю на разных музыкальных инструментах, ожидая, пока время безотказной работы достигнет 30 минут, а затем наблюдаю за результатами top и htop на предмет каких-либо подозрительных изменений — ничего странного.
Случалось ли с кем-то что-то подобное, или кто-то может указать мне правильное направление? Если да, я несколько раз нажму кнопку «Проголосовать за» под вашим ответом (постараюсь, чтобы это было нечетное число).
решение1
Есть несколько способов настроить cron на запуск задания через 30 минут после запуска. Jenkins делает это, хешируя функцию и используя, H/30 * * * *например. Это также может быть поток, спящий в течение 30 минут и порождающий тихий процесс cpu killer.
Вот некоторые идеи:
Вы пробовали htop как root? Некоторые процессы могут быть невидимыми, я видел это особенно на Debian.
Вы пробовали выйти/войти снова, когда возникла проблема? Может быть проблема с оконным менеджером или сеансом.
Если выход/вход не работает, вы можете попробовать перезапустить менеджер сеансов. Я думаю, что по умолчанию это lightdm, так что sudo service lightdm restartэто должно сработать.
решение2
Это было вызваноSMART-данныевключен для соответствующего диска.
Отключение данных SMART решило эту проблему:
sudo smartctl --smart=off /dev/sda
Предположительно, он продолжал перезапускать какую-то внутреннюю самопроверку в течение 30 минут после того, как диск начал вращаться и зациклился; поскольку это происходило на аппаратном уровне, остальная часть компьютера не знала об этом, поэтому я не увидел ни одного процесса, который бы конкретно отвечал за блокировку ввода-вывода, и ни одного процесса, поглощающего ресурсы.