Um job de parada está sendo executado para a sessão c2 do usuário

38

A seguinte mensagem aparece quase toda vez que eu desligo meu computador:

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

Aguarda por 1min30s e continua o processo de desligamento. Eu sigo este guia de diagnóstico de desligamento do systemd e obtenho o shutdown-log.txt (não posso colar diretamente o log aqui porque é muito longo). Infelizmente, não entendo o registro sozinho. Alguém poderia me ajudar a descobrir o que faz meu sistema não desligar corretamente?

Eu corro o Arch Linux com o kernel 4.4.5-1-ARCH , meu systemd versão é 229-3 .

Adição 1: Eu observo que toda vez que eu efetuo logout e, em seguida, encerro meu computador a partir da tela de login, ele não recebe a mensagem A stop job is running... . Eu tentei sair antes de desligar por muitas vezes, então eu acho que isso não ocorre por acaso. Espero que essa informação possa ajudar.

Adição 2: É sempre a sessão c2 que causa o desligamento do desligamento. Então, como @ n.st sugere, eu olhei para Diagnosticando Problemas de Encerramento novamente e armazenei loginctl session-status c2 de dmesg , mas não há nada no shutdown-log.txt . Eu substituí loginctl session-status c2 por systemd-cgls e recebi o seguinte log:

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

Alguma idéia?

Observação: depois de atualizar para o kernel 4.6.4-1-ARCH e systemd 230-7 , o erro não aconteceu mais.

    
por macnguyen 02.04.2016 / 18:23

6 respostas

30

Parece que você pode reduzir o tempo limite em /etc/systemd/system.conf :

DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s

e execute o seguinte comando no terminal depois de fazer alterações

$ systemctl daemon-reload
    
por 21.07.2016 / 11:07
5

Eu encontrei uma solução aqui que funcionou para mim com o Debian 9 no vbox. Eu estava recebendo o atraso típico de 120 segundos no desligamento ou reinício.

link

Faça exatamente como diz Ironman:

The solution is to open shell and "shutdown now" then when the machine comes back on then do a "reboot" and the message goes away and future reboots do not hang anymore.

Eu usei "sudo shutdown now" e o atraso de reinicialização desapareceu. Parece muito simples, mas funcionou para mim (e para os outros).

HTH

    
por 13.02.2018 / 08:15
4

Eu tive o mesmo problema, procurando encontrei uma postagem em um fórum reddit do Arch Linux.

Aqui está a solução que funciona para mim link

Install watchdog

# pacman -S watchdog

And then start the service at boot:

# systemctl enable watchdog.service

Start the service to don't see the message any more

# systemctl start watchdog.service

Eu criei uma essência para este link

    
por 19.05.2016 / 22:49
2

Ter um problema semelhante em Kali [2017.01], com atraso de logout alternado exibido por:

"A stop job is running for Session c1 of user Debian-gdm"

"A stop job is running for User manager for UID 132"

Eu consegui remover um erro parando primeiro o NetworkManager antes do desligamento ou desabilitá-lo, com:

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

Isso provavelmente deve ser corrigido ou colocado de outra maneira ao reinicializar.

Quanto ao outro atraso, não obtive sucesso. Parece que pode estar relacionado ao GDM ( Gnome Display Manager ), pulseaudio ou dbus . Então, como não consegui isolar o problema, a única maneira era definir as DefaultTimeout*Sec=5s entradas em system.conf , como já mencionado em outros posts.

Outras questões que podem ser investigadas são mostradas em:

# 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.

e:

# systemd-cgls -u user-132.slice

Unit user-132.slice (/user.slice/user-132.slice):
├─[email protected]
│ ├─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
    
por 13.12.2017 / 13:36
1

Como esse é um dos primeiros resultados do mecanismo de pesquisa mais amigável de todos os tempos, adicionarei minha solução aqui: Eu estou usando o Arch Linux com o desktop Gnome; kernel atual a partir de hoje: 4.16.

Eu recebi a mensagem A stop job is running for Session c2 of user ... (1min 30s) sempre que Remote Login foi ativado em Settings > Sharing e Sharing foi ativado.

Sempre que eu desabilitava isso, meu computador desligava bem usando o botão de desligamento do Gnome.

Como o "Login Remoto" não é senão o SSH, presumo que a resposta do not2qubit também funcionará, porque a desativação do NetworkManager provavelmente também desativará o SSH.

    
por 25.04.2018 / 20:55
0

Às vezes, isso pode ser causado por um aplicativo. Lembrar as alterações feitas antes que isso aconteça pode ser útil para identificar a causa. Eu tive o mesmo problema depois de instalar o skypeforlinux-stable-bin no Arch Linux. Fechar esse aplicativo antes de desligar resolveu o problema (eu escrevi um script para que isso fosse feito automaticamente antes de desligar).

    
por 03.08.2018 / 11:15