Задание остановки выполняется для сеанса c2 пользователя

Следующее сообщение появляется почти каждый раз, когда я выключаю компьютер:

A stop job is running for Session c2 of user ... (1min 30s)

Он ждет 1 мин 30 с, затем продолжает процесс выключения. Я следую этому руководству по диагностике выключения systemd и получаю shutdown-log.txt (я не могу вставить сюда журнал напрямую, потому что он очень длинный). К сожалению, я не понимаю журнал самостоятельно. Может ли кто-нибудь помочь мне выяснить, что заставляет мою систему не выключаться должным образом?

Я запускаю Arch Linux с ядром 4.4.5-1-ARCH, моя systemdверсия 229-3.

Дополнение 1: Я наблюдаю, что каждый раз, когда я выхожу из системы, а затем выключаю компьютер с экрана входа в систему, он не получает сообщение A stop job is running.... Я пытался выйти из системы до выключения много раз, поэтому я думаю, что это не происходит случайно. Надеюсь, что информация может помочь.

Дополнение 2: Это всегда сессия c2, которая вызывает зависание выключения. Поэтому, как подсказывает @ n.st, я снова посмотрел на Диагностику проблем с выключением и сохранил loginctl session-status c2вместо dmesg, но тогда ничего не было shutdown-log.txt. Я заменил loginctl session-status c2на systemd-cglsи получил следующий журнал:

Control group /:
-.slice
└─init.scope
  ├─   1 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1069 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1071 /bin/sh /usr/lib/systemd/system-shutdown/debug.sh reboot
  └─1074 systemd-cgls

Есть идеи?

Примечание: После того, как я обновил ядро 4.6.4-1-ARCHи systemd 230-7ошибка больше не произошла.

Обойти эту проблему можно, сократив время ожидания /etc/systemd/system.confс 90 до, например, 10 секунд:

DefaultTimeoutStopSec=10s

и выполните следующую команду в терминале после внесения изменений

$ systemctl daemon-reload

Эта проблема может иметь много причин, поэтому конкретные ответы не работают слишком хорошо. Попробуйте это для устранения неполадок:

1. дождитесь появления сообщения «Остановка задания для сеанса c2 ...» при завершении работы и перезагрузите компьютер после завершения завершения работы
2. запустите journalctl -p5в терминале и нажмите, ENDчтобы добраться до конца журнала systemd ( -p5отфильтровывает много мусора)
3. начните поиск, нажав /и введите условие поискаtimed out. Killing.
4. искать в обратном направлении, нажимая SHIFT+Nнесколько раз
5. строка под каждым совпадением говорит вам, какое приложение плохо себя ведет:Killing process 1234 (jack_thru) with signal SIGKILL.

Если это всегда одно и то же приложение, вы хотите узнать, что оно делает и почему его не остановить при завершении работы. В противном случае решение проблемы может оказаться более сложным, но вы все равно можете получить подсказку или два.

Удачи! :)

У меня была такая же проблема, при поиске я нашел сообщение на форуме Reddit Arch Linux.

Вот решение, которое работает для меня https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u

Установить сторожевой таймер

# pacman -S watchdog

А затем запустите службу при загрузке:

# systemctl enable watchdog.service

Запустите сервис, чтобы больше не видеть сообщения

# systemctl start watchdog.service

Я создаю суть для этого https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3

Я нашел здесь решение, которое работало для меня с Debian 9 на vbox. Я получал типичную 120-секундную задержку при выключении или перезагрузке.

https://forums.kali.org/showthread.php?32498-Delay-90-seconds-on-shutdown

Делайте так, как говорит Ironman:

Решение состоит в том, чтобы открыть оболочку и «выключить сейчас», а затем, когда машина снова включается, выполнить «перезагрузку», и сообщение исчезнет, ​​и будущие перезагрузки больше не будут зависать.

Я использовал «sudo shutdown now» и задержка перезапуска теперь прошла. Кажется слишком простым, но это сработало для меня (и других).

НТН

Имея аналогичную проблему на Kali [2017.01], с чередующейся задержкой выхода из системы, отображаемой:

«Задание остановки запущено для сеанса c1 пользователя Debian-gdm»

«Задание остановки выполняется для диспетчера пользователей для UID 132»

Мне удалось устранить одну ошибку, остановившись NetworkManagerперед выключением или отключив ее, с помощью:

# To get rid of: "A stop job is running for User manager for UID 132"
systemctl disable NetworkManager 
systemctl stop NetworkManager 

Вероятно, это следует исправить или поставить другим способом при перезагрузке.

Что касается другой задержки, я не был успешным. Кажется, что это может быть связано с GDM ( Gnome Display Manager ) pulseaudioили dbus. Так как я не смог изолировать проблему, единственным способом было установить DefaultTimeout*Sec=5sзаписи, system.confкак уже упоминалось в других сообщениях.

Другие проблемы, которые могут быть исследованы, показаны в:

# systemctl --state=masked --state=not-found --state=failed

  UNIT                           LOAD      ACTIVE   SUB  DESCRIPTION                   
● tmp.mount                      not-found inactive dead tmp.mount                     
● auditd.service                 not-found inactive dead auditd.service                
● console-screen.service         not-found inactive dead console-screen.service        
● festival.service               not-found inactive dead festival.service              
● kbd.service                    not-found inactive dead kbd.service                   
● live-tools.service             masked    inactive dead live-tools.service            
● plymouth-quit-wait.service     not-found inactive dead plymouth-quit-wait.service    
● plymouth-quit.service          not-found inactive dead plymouth-quit.service         
● plymouth-start.service         not-found inactive dead plymouth-start.service        
● systemd-sysusers.service       not-found inactive dead systemd-sysusers.service      
● systemd-update-done.service    not-found inactive dead systemd-update-done.service   
● systemd-vconsole-setup.service not-found inactive dead systemd-vconsole-setup.service
● syslog.target                  not-found inactive dead syslog.target                 

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

а также:

# systemd-cgls -u user-132.slice

Unit user-132.slice (/user.slice/user-132.slice):
├─user@132.service
│ ├─pulseaudio.service
│ │ └─739 /usr/bin/pulseaudio --daemonize=no
│ ├─at-spi-dbus-bus.service
│ │ ├─704 /usr/lib/at-spi2-core/at-spi-bus-launcher
│ │ ├─709 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
│ │ └─712 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
│ ├─dbus.service
│ │ └─694 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
│ └─init.scope
│   ├─597 /lib/systemd/systemd --user
│   └─600 (sd-pam)
└─session-c1.scope
  ├─577 gdm-session-worker [pam/gdm-launch-environment]
  ├─613 /usr/lib/gdm3/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
  ├─618 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/132/gdm/Xauthority -background none -noreset -keeptty -verbose 3
  ├─697 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
  ├─721 /usr/bin/gnome-shell
  └─752 /usr/lib/gnome-settings-daemon/gnome-settings-daemon

Так как это один из первых результатов в самой дружественной поисковой системе, я добавлю свое решение здесь: я использую Arch Linux с рабочим столом Gnome; текущее ядро ​​на сегодня: 4.16.

Я получал сообщение A stop job is running for Session c2 of user ... (1min 30s)всякий раз, когда Remote Loginбыл активирован в Settings > Sharingи Sharingбыл активирован.

Всякий раз, когда я отключал это, мой компьютер хорошо выключался с помощью кнопки выключения Gnome.

Поскольку «Удаленный вход в систему» ​​является ничем иным, как SSH, я предполагаю, что ответ not2qubit также будет работать, потому что отключение NetworkManager, вероятно, также отключит SSH.

Иногда это может быть вызвано одним приложением. Запоминание изменений, внесенных непосредственно перед тем, как это произойдет, может помочь определить причину. У меня была такая же проблема после установки skypeforlinux-stable-binна Arch Linux. Закрытие этого приложения перед закрытием решило проблему (я написал скрипт, чтобы сделать это автоматически перед выключением).

У меня была эта проблема в течение долгого времени, поэтому я решил поделиться своим решением.

Проблема заключалась в том, что Google Chrome работает в фоновом режиме и не закрывается при выключении компьютера. Поэтому лучшее решение - отключить эту функцию.

1. Зайдите в настройки Google Chrome.
2. Нажмите «Дополнительно».
3. Перейти в «Система».
4. Отключите «Продолжать запуск фоновых приложений, когда Google Chrome закрыт».

Это решило это для меня. Надеюсь, это поможет.