Определенные процессы, которые вы перечислили, нормальные - в основном это компоненты GNOME, такие как индексатор файлов или демон хранения почты / календаря. Они, вероятно, должны были выйти, но пост не содержит достаточно информации, чтобы ответить, должна ли система их активно убивать.
Я знаю, что у меня могут быть процессы, "отключенные" и устойчивые к HANGUP, но я не делал ничего подобного.
Вся идея "отсоединения" процесса применима только в том случае, если процесс был подключен к терминалу в первую очередь. Ни один из ваших графических процессов сеанса не начинается таким образом; они никогда не имеют управляющего терминала, и их ввод / вывод просто идет в лог-файл, если вообще где-либо. Поскольку сигнал зависания генерируется, когда исчезает управляющий tty (например, буквально "зависает"), отсутствие управляющего tty означает, что ни один из них не будет сгенерирован.
(Хотя даже если вы действительно запускаете процесс из терминала, это не мешает ему добровольно "отсоединиться" от этого терминала (что называется "демонизация"). Перед интегрированными менеджерами сервисов, такими как launchd или systemd, все фоновые сервисы, такие как sshd или inetd, будут запускаться из терминала и отключаться без явного запроса.)
Для грубого большинства ваших графических процессов сеанса близким эквивалентом может быть X-сервер (Xorg). Они могут поддерживать явный сигнал «пожалуйста, выйдите» через SM, но обычно они просто выходят, когда Xorg завершает работу и соединение с ним теряется. Но это не сигнал; это добровольно со стороны программы, и иногда программа не сразу, потому что она занята чем-то другим и не замечает.
Большая часть ваших перечисленных процессов на самом деле является демонами / сервисами, которые даже не используют X11. Например, gvfsd - это демон виртуальной файловой системы GNOME, который обычно используется только графическими программами, но сам по себе не зависит от X11. Аналогично, tracker-miner является сервисом индексации файлов - он вообще не использует X11. (Но оба оказываются сервисами D-Bus, поэтому они делают то же самое, когда выходит dbus-daemon и теряется соединение с шиной.)
Кроме того: в Linux традиционно не было общесистемной концепции "полностью включенного сеанса входа в систему" до тех пор, пока ... ну, пока systemd-logind не начал использовать cgroups для инкапсуляции процессов сеанса. До этого, случайный процесс или два после выхода из системы был обычным явлением. Теперь, если вы настроите logind для уничтожения всех пользовательских процессов при выходе из системы, он будет убивать все пользовательские процессы при выходе из системы.
Однако, нередко, что один и тот же процесс демона будет разделен между сеансами одного и того же пользователя - например, между графическим сеансом и входом в систему по SSH - так что более поздние версии logind перенесли акцент с отдельных сеансов на пользователей. (На самом деле, systemd даже ввел новую концепцию "обслуживания пользователей" через «systemctl --user».) Теперь, даже если вы выйдете из GNOME или KDE, но по-прежнему будете входить через SSH, ваши процессы не будут уничтожены, потому что вы все еще вошли в систему! (Это, в частности, влияет на службы D-Bus, упомянутые ранее: шина больше не относится к графическому сеансу, а теперь используется для всей учетной записи пользователя.)
Этот последний бит означает, что вы получите полезные результаты только в том случае, если вы выполните проверку процесса через соединение, вошедшее в систему напрямую как пользователь root (или какой-либо другой пользователь).
