È in esecuzione un processo di arresto per la sessione c2 dell'utente

56

Il seguente messaggio appare quasi ogni volta che spengo il computer:

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

Attende 1 minuto e 30 minuti, quindi continua il processo di spegnimento. Seguo questa guida alla diagnosi dello spegnimento del sistema e ottengo lo shutdown-log.txt (non riesco a incollare direttamente il registro qui perché è molto lungo). Sfortunatamente, non capisco il registro da solo. Qualcuno potrebbe aiutarmi a scoprire ciò che rende il mio sistema non si spegne correttamente?

Corro Arch Linux con il kernel 4.4.5-1-ARCH, la mia systemdversione è 229-3.

Aggiunta 1: osservo che ogni volta che esco, quindi spengo il computer dalla schermata di accesso, non viene visualizzato il messaggio A stop job is running.... Ho provato a disconnettermi prima dell'arresto per molte volte, quindi penso che non si verifichi per caso. Spero che le informazioni possano aiutare.

Aggiunta 2: è sempre la sessione c2 a causare l'arresto del sistema. Come suggerito da @ n.st, ho esaminato di nuovo Diagnosi dei problemi di spegnimento e memorizzato loginctl session-status c2invece di dmesg, ma poi non c'è nulla sul shutdown-log.txt. Ho sostituito loginctl session-status c2dal systemd-cglsed ho ottenuto il seguente registro:

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

Qualche idea?

Nota: dopo l'aggiornamento al kernel 4.6.4-1-ARCHe systemd 230-7l'errore non si è più verificato.

systemd shutdown

— macnguyen
fonte

Purtroppo l' dmesgoutput incollato non è molto informativo: mostra la disconnessione WiFi quando si preme il pulsante di spegnimento (3048 secondi dopo l'avvio del sistema) e quindi nulla fino alla scadenza del timer 1m30 e il sistema continua a spegnersi (a 3139 secondi).

— n.

1

Per verificare ciò che è in esecuzione in quella sessione inquietante c2 che non si interrompe da solo, utilizzare loginctl session-status c2. Non sono sicuro se puoi ancora passare a un getty durante l'arresto, ma prova a premere Ctrl + Alt + F2 quando viene visualizzato "A stop job is ...". Se funziona, otterrai un prompt di accesso e sarai in grado di usare il loginctlcomando. Se non ricevi un prompt di accesso, segui gli stessi passaggi usati per dmesg, ma memorizza invece l'output di loginctl session-status c2. (Tutto questo presuppone che sia sempre "c2" sospeso, non un'altra sessione ogni volta.)

— n.

1

Potresti ottenere una correzione (temporanea) da questo hack: Crea /etc/sysctl.d/50-coredump.confcon contenuto kernel.core_pattern=core

— :,

1

github.com/systemd/systemd/issues/2691 Questo potrebbe essere rilevante

— Natecat

2

@aurelien È sempre c2 a causare lo spegnimento del timer? In tal caso, è possibile seguire nuovamente Diagnosi di problemi di arresto e archiviare loginctl session-status c2invece di dmesg.

— n.

45

Una soluzione alternativa a questo problema consiste nel ridurre questo timeout /etc/systemd/system.confda 90s a 10s ad esempio:

DefaultTimeoutStopSec=10s

ed esegui il seguente comando nel terminale dopo aver apportato le modifiche

$ systemctl daemon-reload

— MightyPork
fonte

9

questo non spiega o risolve il problema, anche aspettare 10 secondi e nemmeno avere un arresto pulito non è affatto eccezionale

— jcora

C'è qualche lavoro che impiega più di 10 secondi per fermarsi?

— Jared Chu,

10

Questo problema può avere molte cause, quindi le risposte specifiche non funzionano troppo bene. Prova questo per la risoluzione dei problemi:

attendere che venga visualizzato il messaggio "Un processo di arresto è in esecuzione per la sessione c2 ..." all'arresto e al riavvio al termine dell'arresto
eseguire journalctl -p5in un terminale e premere ENDper arrivare alla fine del journal di systemd ( -p5filtra un sacco di immondizia)
avviare una ricerca premendo /e immettere il termine di ricercatimed out. Killing.
cerca all'indietro premendo SHIFT+Nripetutamente
la riga sotto ogni corrispondenza indica quale applicazione si stava comportando male:Killing process 1234 (jack_thru) with signal SIGKILL.

Se è sempre la stessa applicazione, vuoi scoprire cosa fa e perché non viene arrestato allo spegnimento. Altrimenti potrebbe essere più complicato risolvere il problema, ma potresti comunque avere un suggerimento o due.

In bocca al lupo! :)

— mzuther
fonte

1

Grazie per questa risposta corretta. L'ho usato per scoprire che nel mio caso Fedora era la causa delle notifiche "lpf", e in lpf-gui deselezionate Notifiche | Attivare le notifiche.

— vk5tu,

5

Ho avuto lo stesso problema, cercando ho trovato un post in un forum reddit di Arch Linux.

Ecco la soluzione che funziona per me https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u

Installa il cane da guardia

# pacman -S watchdog

E quindi avviare il servizio all'avvio:

# systemctl enable watchdog.service

Avviare il servizio per non visualizzare più il messaggio

# systemctl start watchdog.service

Creo un'idea per questo https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3

— Diego Juliao
fonte

Ho seguito la tua guida, ma non risolve il problema. Grazie lo stesso.

— macnguyen,

2

Ci sono altre implicazioni per questa correzione? Apparentemente l' watchdog hardware ripristinerà il sistema se è in ritardo o fallisce altri test. Pertanto, quando si verifica il timeout nella domanda, il watchdog ripristinerà il computer. Mi chiedo se il sistema si spegnerebbe in modo più pulito se riducessimo il timeout secondo l' altra risposta. Mi chiedo anche se watchdogforzerebbe un ripristino in altre situazioni indesiderate.

— Sparhawk,

Ho letto la tua pagina man . Penso che il cane da guardia impedisca il reset dicendo al kernel di Linux che tutto è OK,

— Diego Juliao,

> Apre / dev / watchdog e continua a scriverlo abbastanza spesso da impedire il reset del kernel, almeno una volta al minuto.

— Diego Juliao,

Nessun pacchetto chiamato watchdog su OpenSuSE, quindi questo non mi aiuta davvero :(

— David Faure,

4

Ho trovato una soluzione qui che ha funzionato per me con Debian 9 su vbox. Stavo ottenendo il tipico ritardo di 120 secondi allo spegnimento o al riavvio.

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

Fai come dice Ironman:

La soluzione è aprire la shell e "arrestare ora", quindi quando la macchina si riaccende, quindi eseguire un "riavvio" e il messaggio scompare e i riavvii futuri non si bloccano più.

Ho usato "sudo shutdown now" e il ritardo di riavvio è scomparso. Sembra troppo semplice, ma ha funzionato per me (e altri).

HTH

— Dennis Cote
fonte

8

Perché questa risposta ha così tanti voti positivi? Non ha funzionato per me e non fornisce alcun indizio sul perché dovrebbe funzionare.

— Rodrigo

Ha funzionato per me, ma non è ancora chiaro il perché.

— pstryk,

3

Avendo avuto un problema simile su Kali [2017.01], con un ritardo di logout alternato visualizzato da:

"È in esecuzione un processo di arresto per la sessione c1 dell'utente Debian-gdm"

"È in esecuzione un processo di arresto per User manager per UID 132"

Sono riuscito a eliminare un errore fermandomi NetworkManagerprima dell'arresto o disabilitandolo, con:

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

Questo dovrebbe probabilmente essere risolto o messo in un altro modo al riavvio.

Per quanto riguarda l'altro ritardo, non ho avuto successo. Sembra che possa essere correlato a GDM ( Gnome Display Manager ) pulseaudioo dbus. Quindi poiché non sono stato in grado di isolare il problema, l'unico modo era impostare le DefaultTimeout*Sec=5svoci system.confcome già menzionato in altri post.

Altri problemi che possono essere esaminati sono mostrati in:

# 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):
├─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

— not2qubit
fonte

2

Questa risposta ci fornisce almeno alcune informazioni su come trovare quale (tra le molte possibilità) potrebbe causare il problema sui nostri singoli computer. Ancora un altro problema è che dopo un poweroffo shutdownnon possiamo accedere per vedere il vero colpevole. systemd deve registrare l'output di cgls quando si verifica questo problema. Il meglio che possiamo fare per ora è salvare l'output systemd-cglse consultarlo in seguito se / quando si verifica nuovamente il blocco.

— duanev,

2

Poiché questo è uno dei primi risultati nel motore di ricerca più amichevole di sempre, aggiungerò qui la mia soluzione: sto usando Arch Linux con desktop Gnome; kernel attuale ad oggi: 4.16.

Ho ricevuto il messaggio A stop job is running for Session c2 of user ... (1min 30s)ogni volta che è Remote Loginstato attivato Settings > Sharinge Sharingattivato.

Ogni volta che lo disabilitavo, il mio computer si spegneva bene usando il pulsante di spegnimento di Gnome.

Poiché "Accesso remoto" non è altro che SSH, suppongo che anche la risposta di not2qubit funzionerà, poiché la disabilitazione di NetworkManager probabilmente disabiliterà anche SSH.

— stueja
fonte

1

A volte ciò può essere causato da un'app. Ricordare le modifiche apportate appena prima che ciò accada può essere utile per individuare la causa. Ho avuto lo stesso problema dopo l'installazione skypeforlinux-stable-binsu Arch Linux. Chiudendo quell'app prima di chiudere ho risolto il problema (ho scritto uno script per farlo automaticamente prima di spegnerlo).

— prosoitos
fonte

0

Ho avuto questo problema per molto tempo, quindi ho pensato di condividere la mia soluzione.

Il problema era che Google Chrome è in esecuzione in background e non si chiude quando si spegne il computer. Quindi la soluzione migliore è disattivare quella funzione.

Vai alle impostazioni di Google Chrome.
Fai clic su "Avanzate".
Vai a "Sistema".
Disabilita "Continua a eseguire app in background quando Google Chrome è chiuso".

Questo mi ha risolto. Spero che sia d'aiuto.

— ArianJM
fonte