Distribution
mint 22.3 cinnamon
Package version
Cinnamon 6.6.7
Graphics hardware in use
GPU 1: AMD Radeon HD 6630M/6650M/6750M/7670M/7690M GPU 2: Intel 2nd Generation Core Processor Family Integrated
Frequency
Always
Bug description
Subject:
Race condition between lightdm and gnome-keyring-daemon (gkr-pam) on legacy hardware.
System Environment:
Host: iMac 12,1 (2011)
OS: Linux Mint 22.3 x86_64
Kernel: 6.17.0-22-generic
DE: Cinnamon 6.6.7
Display Manager: LightDM
Problem Description:
At system startup, journalctl logs consistently show errors related to gkr-pam. Although the keyring is eventually unlocked successfully after login , the system generates error messages during the LightDM session initialization. This occurs because the PAM module attempts to communicate with the keyring daemon before the control socket has been created in the temporary filesystem (/run/user/1000/).
Relevant Logs (journalctl -b 0):
Plaintext
lightdm[PID]: gkr-pam: couldn't unlock the login keyring.
lightdm[PID]: gkr-pam: unable to locate daemon control file
lightdm[PID]: gkr-pam: stashed password to try later in open session
lightdm[PID]: gkr-pam: unlocked login keyring
Technical Analysis:
The issue is a pure race condition. On hardware with asynchronous I/O initialization times (such as legacy iMacs), the LightDM authentication sequence precedes the availability of the user session bus. The pam_gnome_keyring.so module fails the first two attempts during the auth phase and only succeeds in the third attempt during the session phase. This results in redundant, non-critical warnings that clutter the system logs.
Proposed Solutions / Mitigation:
PAM Configuration Optimization: Evaluate moving the auto_start parameter exclusively to the session phase within /etc/pam.d/lightdm. This would prevent the auth phase from attempting to initialize the daemon when the required sockets are not yet available.
Delay/Retry Logic: Implement or suggest a small delay in the execution of gkr-pam within LightDM to allow systemd --user enough time to correctly map the /run/user/ directories.
Cleanup of Default Configuration: Consider removing or commenting out references to pam_kwallet.so by default in Cinnamon (non-KDE) installations to avoid unnecessary unlock attempts for missing modules, which slow down the PAM chain.
NOTE:
System:
Kernel: 6.17.0-22-generic arch: x86_64 bits: 64
Desktop: Cinnamon v: 6.6.7 Distro: Linux Mint 22.3 (Zena)
Machine:
Type: Desktop System: Apple product: iMac12,1 v: 1.0
serial:
Mobo: Apple model: Mac-942B5BF58194151B serial:
UEFI: Apple v: 87.0.0.0.0 date: 06/14/2019
CPU:
Info: quad core model: Intel Core i5-2400S bits: 64 type: MCP cache:
L2: 1024 KiB
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
driver: i915 v: kernel
Device-2: AMD Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M]
driver: radeon v: kernel
Steps to reproduce
Boot the system (Linux Mint 22.3 Cinnamon) on legacy hardware (e.g., iMac 2011).
Reach the LightDM login screen.
Enter user credentials and log in.
Open the terminal and check system logs using journalctl -b 0 | grep gkr-pam.
Expected behavior
The system logs show multiple failed attempts by gkr-pam to locate the daemon control file during the auth phase, resulting in "couldn't unlock" warnings. Success is only achieved in the final session phase, causing redundant error noise in the boot logs.
Additional information
No response
Distribution
mint 22.3 cinnamon
Package version
Cinnamon 6.6.7
Graphics hardware in use
GPU 1: AMD Radeon HD 6630M/6650M/6750M/7670M/7690M GPU 2: Intel 2nd Generation Core Processor Family Integrated
Frequency
Always
Bug description
Subject:
Race condition between lightdm and gnome-keyring-daemon (gkr-pam) on legacy hardware.
System Environment:
Problem Description:
At system startup, journalctl logs consistently show errors related to gkr-pam. Although the keyring is eventually unlocked successfully after login , the system generates error messages during the LightDM session initialization. This occurs because the PAM module attempts to communicate with the keyring daemon before the control socket has been created in the temporary filesystem (/run/user/1000/).
Relevant Logs (journalctl -b 0):
Plaintext
lightdm[PID]: gkr-pam: couldn't unlock the login keyring.
lightdm[PID]: gkr-pam: unable to locate daemon control file
lightdm[PID]: gkr-pam: stashed password to try later in open session
lightdm[PID]: gkr-pam: unlocked login keyring
Technical Analysis:
The issue is a pure race condition. On hardware with asynchronous I/O initialization times (such as legacy iMacs), the LightDM authentication sequence precedes the availability of the user session bus. The pam_gnome_keyring.so module fails the first two attempts during the auth phase and only succeeds in the third attempt during the session phase. This results in redundant, non-critical warnings that clutter the system logs.
Proposed Solutions / Mitigation:
NOTE:
System:
Kernel: 6.17.0-22-generic arch: x86_64 bits: 64
Desktop: Cinnamon v: 6.6.7 Distro: Linux Mint 22.3 (Zena)
Machine:
Type: Desktop System: Apple product: iMac12,1 v: 1.0
serial:
Mobo: Apple model: Mac-942B5BF58194151B serial:
UEFI: Apple v: 87.0.0.0.0 date: 06/14/2019
CPU:
Info: quad core model: Intel Core i5-2400S bits: 64 type: MCP cache:
L2: 1024 KiB
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
driver: i915 v: kernel
Device-2: AMD Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M]
driver: radeon v: kernel
Steps to reproduce
Boot the system (Linux Mint 22.3 Cinnamon) on legacy hardware (e.g., iMac 2011).
Reach the LightDM login screen.
Enter user credentials and log in.
Open the terminal and check system logs using journalctl -b 0 | grep gkr-pam.
Expected behavior
The system logs show multiple failed attempts by gkr-pam to locate the daemon control file during the auth phase, resulting in "couldn't unlock" warnings. Success is only achieved in the final session phase, causing redundant error noise in the boot logs.
Additional information
No response