Завдання зупинки виконується для сесії c2 користувача

Таке повідомлення з’являється майже кожного разу, коли вимикаю комп'ютер:

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

Він чекає 1min30s, а потім продовжує процес відключення. Я дотримуюся цього посібника з діагностики закритого вимикання і отримую 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щоб дійти до кінця системного журналу ( -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", і затримка перезапуску вже пішла. Здається, занадто просто, але це працювало для мене (та інших).

HTH

Виникли подібні проблеми з 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 закритий".

Це вирішило це для мене. Сподіваюся, це допомагає.