Бионический бобер, 18.04.
Сегодня произошел забавный случай. У меня есть система, работает нормально, загружается до рабочего стола - время безотказной работы около 80 дней, на рабочем столе открывается много окон. Все в порядке, пока... GUI не работает на tty1 (как и ожидалось).
Пытаясь отладить другую проблему, я решил переключиться с графического интерфейса рабочего стола на виртуальную консоль и войти в систему. Итак, я делаю «sudo chvt 2» и получаю приглашение для входа в систему на tty2. Все идет нормально. Я вхожу в систему как сам (на tty2), делаю несколько вещей, затем выхожу из системы (через ^D) - ожидая вернуться к приглашению для входа, из которого я могу затем вернуться к сеансу рабочего стола с графическим интерфейсом.
Однако следующее, что происходит, это то, что я вижу чисто фиолетовый экран, а затем, примерно через 10 секунд, экран с графическим интерфейсом, запрашивающий мой пароль. Я вхожу в систему и вижу чистый, свежий рабочий стол. Все окна, которые были раньше, исчезли (имеется в виду, что я должен выяснить, что там было раньше, и перезапустить все).
Похоже, что каким-то образом выход из tty2 отправил сигнал зависания всем процессам, запущенным на рабочем столе с графическим интерфейсом, включая сам рабочий стол, заставив вас снова войти в систему и перезапустить все, что было запущено раньше.
Почему это происходит?
Некоторая дополнительная информация:
После перезапуска рабочего стола - и после того, как я запустил свои сценарии, чтобы открыть мои обычные окна (программы), - я обнаружил, что существует лабиринт процессов, работающих на tty1, работающих от имени пользователя "gdm", а также лабиринт обрабатывается на tty3, работает от имени пользователя «я». Все эти процессы (как на tty1, так и на tty3) отображаются как запущенные во время перезапуска рабочего стола. На tty2 работает один процесс (getty).
В /var/crash есть один файл с отметкой времени перезапуска рабочего стола, который соответствует одному из моих процессов (то есть тому, что я запускал в одном из окон терминала во время сбоя). Этот файл показывает, что он был уничтожен сигналом 6 (SIGABRT). SIGABRT обычно вызывается ошибкой программы в assert(3).
