Sddm no reboot poweroff al login

[Ombra]

@Lioce: scusa ma non avevo capito bene il problema, se al login i pulsanti non sono cliccabili ma all'uscita, senza fare nulla invece si... (ho capito bene?) forse allora il riavvio di sddm non centra nulla e il problema è tutt'altro.
Per curiosità, al login (quando i pulsanti non sono cliccabili) vai in vt1 e esegui

Codice: Seleziona tutto

 $ loginctl 

poi torni in vt7 ed effettui il login con sddm, a quel punto esegui nuovamente

Codice: Seleziona tutto

$ loginctl 

il risultato dei due comandi è identico o cambiano? riesci a postarli?

[Lioce]

@Lioce: scusa ma non avevo capito bene il problema, se al login i pulsanti non sono cliccabili ma all'uscita, senza fare nulla invece si... (ho capito bene?)

Sì, hai capito bene, mi dispiace di non averlo precisato subito. Il problema si verifica solo al login.
Al logout nel menu Kickoff sotto la voce esci sono presenti tutte le varie opzioni: spegni, riavvia, chiudi sessione, ecc.
cliccando quella desiderata si apre la schermata di logout con l'opzione scelta cliccabile + countdown + annulla cliccando di nuovo esegue il comando. Tutto regolare.

Per curiosità, al login (quando i pulsanti non sono cliccabili) vai in vt1 e esegui

Codice: Seleziona tutto

 $ loginctl 

poi torni in vt7 ed effettui il login con sddm, a quel punto esegui nuovamente

Codice: Seleziona tutto

$ loginctl 

il risultato dei due comandi è identico o cambiano? riesci a postarli?

Ho rediretto l'output su file e posso postarli, mi sembrano uguali, a parte la sessione in più su tty7 (ho sostituito il vero nome utente con *mio-user*)

loginctl su tty1

Codice: Seleziona tutto

   SESSION        UID USER                  SEAT             TTY             
         2       1000 mio-user              seat0            /dev/tty1       
         1        114 sddm                  seat0                            

2 sessions listed.

loginctl su tty7

Codice: Seleziona tutto

   SESSION        UID USER                  SEAT             TTY             
         3       1000 mio-user              seat0                            
         2       1000 mio-user              seat0            /dev/tty1       
         1        114 sddm                  seat0                            

3 sessions listed.

[Ombra]

OK, i due output di loginctl confermano che sddm ha una sua sessione in entrambi i casi, quindi il problema non è quello che ipotizzavo io all'inizio. A questo punto non so bene come aiutarti.
Noto solo alcune cose, magari possono essere utili:
Il file /etc/sddm.conf l'hai creato tu? perchè non è nel pacchetto sddm di Debian ( a me funziona tutto senza quel file).
Seconda cosa, per cercare informazioni utili nei log relativi a sddm devi guardare in Journal (il log di sistemd) e non nel file /var/log/sddm.log

[Lioce]

@Ombra
grazie lo stesso

Il file /etc/sddm.conf l'hai creato tu? perchè non è nel pacchetto sddm di Debian ( a me funziona tutto senza quel file).

Sì, l'ho creato io, sperando che risolvesse il problema

Codice: Seleziona tutto

sddm --example-config > /etc/sddm.conf

Seconda cosa, per cercare informazioni utili nei log relativi a sddm devi guardare in Journal (il log di sistemd) e non nel file /var/log/sddm.log

Codice: Seleziona tutto

# journalctl
No journal files were found.
-- No entries --

Creare /var/log/journal funziona anche con sysvinit?

[Ombra]

Io le info su sddm le vedo solo nei log di sistema, gli altri files di log sono tutti vuoti. Se non hai Journal avrai un altro log di sistema (syslog-ng?), guarda lì se c'è qualche info utile.

Creare /var/log/journal funziona anche con sysvinit?

Se hai un altro log di sistema journal è disabilitato

[Lioce]

Se non hai Journal avrai un altro log di sistema (syslog-ng?), guarda lì se c'è qualche info utile.

Ho rsyslog.

Dmesg mi dice sempre:

Codice: Seleziona tutto

dmesg | grep -i sddm
[   31.610328] systemd-logind[2687]: New session 1 of user sddm.

In syslog a volte trovo messaggi simili a questo:

Codice: Seleziona tutto

cat /var/log/syslog | grep -i sddm

Jun 11 14:35:50 nome-host dbus[2326]: [system] Activating service name='org.kde.kcontrol.kcmsddm' (using servicehelper)
Jun 11 14:35:51 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:35:51 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:35:51 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:35:51 nome-host dbus[2326]: [system] Successfully activated service 'org.kde.kcontrol.kcmsddm'
Jun 11 14:37:45 nome-host dbus[2326]: [system] Activating service name='org.kde.kcontrol.kcmsddm' (using servicehelper)
Jun 11 14:37:45 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:37:45 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:37:45 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:37:45 nome-host dbus[2326]: [system] Successfully activated service 'org.kde.kcontrol.kcmsddm'
Jun 11 14:38:42 nome-host dbus[2326]: [system] Activating service name='org.kde.kcontrol.kcmsddm' (using servicehelper)
Jun 11 14:38:43 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:38:43 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:38:43 nome-host org.kde.kcontrol.kcmsddm: QDBusArgument: read from a write-only object
Jun 11 14:38:43 nome-host dbus[2326]: [system] Successfully activated service 'org.kde.kcontrol.kcmsddm'

Altre volte non trovo nessun riferimento a org.kde.kcontrol.kcmsddm, come sta succedendo da alcuni giorni.

Ho l'impressione che il problema sia legato a sysvinit.
Potrei provare a disinstallarlo, verificare se il malfunzionamento si presenta anche con systemd e poi reinstallarlo e vedere le differenze.

[Ombra]

Puoi provare a rimuovere temporaneamente kde-config-sddm e vedere se cambia qualcosa;

Ho l'impressione che il problema sia legato a sysvinit.
Potrei provare a disinstallarlo, verificare se il malfunzionamento si presenta anche con systemd e poi reinstallarlo e vedere le differenze.

È sicuramente una prova interessante, aiuterebbe a capire se i tasti non cliccabili sono un comportamento voluto o no.
Il dubbio mi viene perchè guardando degli screenshot in rete ne vedo coi tasti non cliccabili..
Se il problema è circoscritto a sysvinit serve cmq qualche log o indizio che aiuti a capire cosa interviene tra il login e il logout che rende i tasti cliccabili.

[Lioce]

Puoi provare a rimuovere temporaneamente kde-config-sddm e vedere se cambia qualcosa;

Non capisco bene cosa intendi.

Non ho avuto bisogno di eliminare sysvinit. Mi sono ricordato che nella schermata di Grub, in opzioni avanzate, c'è la possibilità di avviare il sistema con systemd.

1) Ho ripristinato il default di /etc/init.d/sddm

Codice: Seleziona tutto

lrwxrwxrwx   1 root root   14 giu 20 08:56 S03sddm -> ../init.d/sddm

2) Ho creato la cartella /var/log/journal
3) e ho riavviato usando l'opzione kernel + systemd.

I pulsanti riavvia e spegni sono apparsi nel greeter con tema Debian Maui, cliccabili.

Altra prova con il tema Brezza: i pulsanti da grigi sono diventati attivi, cliccabili e funzionanti (ho provato).

Allego due log ottenuti con i comandi: journalctl -u sddm.service e cat /var/log/syslog | grep -i sddm

Stasera o domani vedo che succede avviando il sistema con sysvinit.


EDIT
Prova effettuata: avviando il sistema con sysvinit il malfunzionamento si riproduce come prima, ovviamente.
A questo punto mi sembra evidente che il problema dipenda proprio dall'uso di sysvinit.

[Lioce]

Se il problema è circoscritto a sysvinit serve cmq qualche log o indizio che aiuti a capire cosa interviene tra il login e il logout che rende i tasti cliccabili.

I log di sddm li ho trovati in /var/log/authlog, scioccamente non ci ho pensato prima.

Allego gli authlog di due sessioni consecutive *con sysvinit* + l'inizio di quella attuale da cui sto scrivendo.

Che sia un problema di permessi?

Cos'altro posso guardare?

[s3v]

Penso che il problema sia dovuto alla mancanza di ConsoleKit dal sistema o comunque dagli script di avvio.
https://www.freedesktop.org/wiki/Software/ConsoleKit/
Questo spiega anche la frase dello sviluppatore che ho riportato in precedenza.
Purtroppo il progetto è destinato a scomparire e non so se SDDM, pur installandolo, lo supporta.

Sono orientato a credere che anche @Ombra, disinstallando "elogind", sperimenterà lo stesso problema.

[Lioce]

Penso che il problema sia dovuto alla mancanza di ConsoleKit dal sistema o comunque dagli script di avvio.
Purtroppo il progetto è destinato a scomparire e non so se SDDM, pur installandolo, lo supporta.

Ho installato il pacchetto consolekit:

Codice: Seleziona tutto

# apt-get install consolekit
The following additional packages will be installed:
  libck-connector0 libpam-ck-connector
I seguenti pacchetti NUOVI saranno installati:
  consolekit libck-connector0 libpam-ck-connector

Situazione *immutata*: al login pulsanti non cliccabili.
Rimosso.

Se vi interessa posso postare /var/log/ConsoleKit/history e authlog delle sessioni interessate.

[Ombra]

Scusate la latitanza, vari impegni e inoltre ho cercato di individuare il problema guardando i log che sono stati postati ma non ci sono riuscito.
Tendo a escludere che i pulsanti non cliccabili siano voluti, o cmq una situazione inevitabile; infatti anche avendo sysvinit, logind è sempre presente, quindi quello che cambia tra systemd e sysv è l'odine di boot (gestito da sysvinit) e la gestione delle componenti aggiuntive, tra cui logind (gestite dallo shim invece che dallo stesso systemd).
Per me si stratta di un bug, tra sysv, lo shim e sddm, difficile dire esattamente quale. Considerando che l'acoppiata sysv+ lightdm funziona io punto su sddm.
Sto aggiornando una macchina virtuale alla nuova stable, se per caso si riproducesse anche li il problema potrei avere qualche indizio in più sotto mano, per il momento non ho soluzioni..

[s3v]

Situazione *immutata*: al login pulsanti non cliccabili.
Rimosso.

Solo per completezza, puoi verificare che il servizio si trovi in rc2.d?

Altro output:

Codice: Seleziona tutto

$ dpkg -l | grep -i systemd

per capire anche quali sono i pacchetti installai provenienti da systemd.

@ombra
Quella frase è del DD principale per gli upload in Debian di tutto ciò che concerne KDE.
Non saprei se è stata scritta in quel contesto particolare oppure abbia valenza generale, ma a me pare abbastanza chiara.
Per me si tratta di sddm che ha volutamente abbandonato "di default" (o non ha mai avuto) l'autenticazione/permessi della sessione in un sistema senza systemd.
Sicuramente c'è modo di rimetterla ma, sempre a parer mio, con operazioni e/o installazioni di pacchetti che abilitano una funzione non più supportata.

Vedrò anch'io di installare una macchina virtuale con sysv e tentare di replicare il problema.

[s3v]

@Ombra
Grazie, sembra che il problema sia proprio quello da te indicato.
Infatti, dando il secondo comando:

Codice: Seleziona tutto

/etc/init.d/sddm start

appare il greeter con i pulsanti cliccabili sia con il tema Debian Maui che con Brezza.
Al riavvio, però, è tutto come prima.

.
Ops, non ricordavo questa parte. Come non scritto.

[s3v]

Nel file di log che hai postato in altra discussione c'è questo:

Codice: Seleziona tutto

[   31.715747] systemd-logind[2692]: Failed to start user service, ignoring: Unknown unit: user@114.service
[   49.435604] systemd-logind[2692]: Failed to start user service, ignoring: Unknown unit: user@1000.service

Sarebbe utile attivare il debug e leggere i messaggi.