Gkr pam unable to locate daemon control file как исправить
Обновлено: 04.07.2024
Всем привет. Имеется компьютер с Arch Linux и GNOME 3.36 на борту. Используется обычно сессия на Wayland. Столкнулся с такой проблемой - иногда gdm отказывается разблокировать компьютер. Проявляется это так: я блокирую машину нажатием Meta+L, а когда мне нужно разблокировать её ввожу пароль от учётки и ничего дальше не происходит (т.е. даже надпись «неправильный пароль» не появляется, просто сбрасывается текстовое поле и всё), приходится переходить в соседний tty и перезапускать GDM. Я не знаю, куда копать, поэтому единственное, что мне приходит в голову, это скинуть сюда выхлопы команд dmesg и journalctl -rxe
приходится переходить в соседний tty и перезапускать GDM
ещё можно выполнить
и посмотреть что с ним такое случилось. Замечание: возможно эта команда должна выполняться от root или через sudo. В моём Kali Desktop KDE других юзеров просто нет. Ну и сервис может называться не GDM, а как-то иначе.
SSH keys
gnome-keyring-daemon with the ssh component will start an SSH agent and automatically load all the keys in
/.ssh/ that have corresponding .pub files. There is no way to remove these keys from the agent.
To list all loaded keys:
When you connect to a server that uses a loaded key with a password, a dialog will popup asking you for the passphrase. It has an option to automatically unlock the key when you log in. If you check this, you will not need to enter your passphrase again!
To permanently save the a passphrase in the keyring, use ssh-askpass from the seahorse package:
To manually add an SSH key from another directory:
Note: You have to have the corresponding .pub file in the same directory as the private key (/.ssh/id_rsa.pub in the example). Also, make sure that the public key is the file name of the private key plus .pub (for example, my_key.pub ).
To disable all manually added keys:
Disable keyring daemon components
If you wish to run an alternative SSH agent (e.g. ssh-agent or gpg-agent), you need to disable the ssh component of GNOME Keyring. To do so in an account-local way, copy /etc/xdg/autostart/gnome-keyring-ssh.desktop to
/.config/autostart/ and then append the line Hidden=true to the copied file. Then log out.
Note: In case you use GNOME 3.24 or older on Wayland, gnome-shell will overwrite SSH_AUTH_SOCK to point to gnome-keyring regardless if it is running or not. To prevent this, you need to set the environment variable GSM_SKIP_SSH_AGENT_WORKAROUND before gnome-shell is started. One way to do this is to add the following line toUsing the keyring
The PAM module pam_gnome_keyring.so initialises GNOME Keyring partially, unlocking the default login keyring in the process. It should be followed by a call to gnome-keyring-daemon with the --start option to complete initialisation and to set environment variables.
PAM step
- To use automatic unlocking with automatic login, you can set a blank password for the default keyring. Note that the contents of the keyring are stored unencrypted in this case.
- Alternatively, if using GDM and LUKS, GDM can unlock your keyring if it matches your LUKS password. For this to work, you need to use the systemd init in your mkinitcpio.conf as well as the appropriate kernel parameters. See [1] for more details.
- Skipping the PAM step works, because the next step will initialise the daemon when one is not running already; however, the default keyring is not unlocked in this case. More details are available at [2].
When using a display manager, the keyring works out of the box for most cases. GDM, LightDM, LXDM, and SDDM already have the necessary PAM configuration. For a display manager that does not automatically unlock the keyring edit the appropriate file instead of /etc/pam.d/login as mentioned below.
When using console-based login, edit /etc/pam.d/login :
Add auth optional pam_gnome_keyring.so at the end of the auth section and session optional pam_gnome_keyring.so auto_start at the end of the session section.
If you are using GNOME, Unity, Cinnamon, or MATE, you are done. The initialisation is completed and environment variables are set automatically.
--start step
If you are not using GNOME, Unity, Mate, or Cinnamon as your desktop environment, initialisation will not complete automatically. You can fix this using various methods:
Shell
Add the following to your
/.zshenv , or similar:
Xfce only
XDG autostart
Copy gnome-keyring-ssh.desktop , gnome-keyring-pkcs11.desktop , and gnome-keyring-secrets.desktop from /etc/xdg/autostart/ to
/.config/autostart/ and delete the OnlyShowIn=GNOME;Unity;MATE;Cinnamon; lines from each file. Note however that this will not set SSH_AUTH_SOCK (and the other variables if the PAM step was skipped) environment variable.
GNOME/Keyring
gnome-keyring is a member of the gnome group is thus usually present on systems running GNOME. The package can otherwise be installed on its own. libsecret should also be installed to grant other applications access to your keyrings. Although libgnome-keyring is deprecated (and superseded by libsecret), it may still be required by certain applications.
Extra utilities related to GNOME Keyring include:
Note: gnome-keyring-query only requires libgnome-keyring as a build dependency.Troubleshooting
Passwords are not remembered
If you are prompted for a password after logging in and you find that your passwords are not saved, then you may need to create/set a default keyring. To do this using Seahorse (a.k.a. Passwords and Keys), see Create a new keyring and Change the default keyring in GNOME Help.
Resetting the keyring
You will need to change your login keyring password if you receive the following error message: "The password you use to login to your computer no longer matches that of your login keyring".
Alternatively, you can remove the login.keyring and user.keystore files from
/.local/share/keyrings/ . Be warned that this will permanently delete all saved keys. After removing the files, simply log out and log in again.
Unable to locate daemon control file
The following error may appear in the journal after logging in:
This message "can be safely ignored" if there are no other related issues [3].
Manage using GUI
You can manage the contents of GNOME Keyring using Seahorse; install the seahorse package.
Passwords for keyrings (e.g., the default keyring, "Login") can be changed and even removed. See Create a new keyring and Update the keyring password in GNOME Help for more information.
Arch Linux
REPEAT: Do NOT report bugs for outdated packages!
| Task Type | Bug Report |
|---|---|
| Category | Packages: Extra |
| Status | Assigned |
| Assigned To | Maxime Gauduin (Alucryd) |
| Architecture | x86_64 |
| Severity | Medium |
| Priority | Normal |
| Reported Version | |
| Due in Version | Undecided |
| Due Date | Undecided |
| Percent Complete |  |
| Votes | 34 |
Details
Description:
Systemd journal reports
lightdm[455]: gkr-pam: unable to locate daemon control file
lightdm seems to work fine, allowing me to log in and continue operation.
This issue did not exist in 1:1.28.0-1
Additional info:
* package version(s): 1:1.28.0-3
Steps to reproduce:
1. Let lightdm launch
2. Check systemd journal
This task depends upon
The last error recorded in my journal before my system locked up:
`Sep 12 07:41:37 k3 lightdm[849]: gkr-pam: unable to locate daemon control file`
Unable to bring up a virtual terminal: Ctrl + Alt + F1, (F1-F6). Mouse frozen, etc.
Happens at random times.
Same behavior for XFCE and GNOME.
Will downgrade lightdm and try for a while to see if the system locks stop.
Kernel: 5.2.13-arch1-1-ARCH x86_64 bits: 64 compiler: gcc v: 9.1.0 Desktop: Xfce 4.14.1 Distro: Arch Linux
lightdm version: 1.30.0
After downgrading from lightdm 1.30.0 to 1.28.0 I have discovered that downgrading did not help. My system is still locking up with the same `Sep 14 15:07:03 k3 lightdm[852]: gkr-pam: unable to locate daemon control file` message.
Any recommendations on how best to troubleshoot this issue?
I also have this bug. System locks up randomly and i get the gkr-pam: unable to locate daemon control file on journal I have the bug with gnome-keyring 3.36, lightdm 1.30 with Kernel 5.8.6Sender lightdm
Time 19:27:25
Message gkr-pam: unable to locate daemon control file
Priority 3
Same issue with gdm
Bugged when I boot with enabled service
Works if I start service after boot
Should help in general to fix this annoying error, if it can be implemented in time or there is enough developer effort.
I think one possible explanation to this is:
Hi,
i have some issues with lightdm and lightlocker. I do not understand which does whom affect.
Unlocking the desktop with light-locker is buggy. And sometimes lightdm has back traces.
How can i track this down?
The text was updated successfully, but these errors were encountered:
Linuxfreak2 commented Apr 29, 2019
right after unlocking the screen-locker:
Apr 29 18:17:07 lightdm[9653]: gkr-pam: unable to locate daemon control file
Apr 29 18:17:11 systemd-coredump[9659]: Process 690 (xfwm4) of user 1000 dumped core.
Tips and tricks
Integration with applications
Flushing passphrases
This command starts gnome-keyring-daemon, shutting down previously running instances.
Git integration
Configure Git to use the libsecret helper:
The next time you run git push , you will be asked to unlock your keyring if it is not already unlocked.
GnuPG integration
Several applications which use GnuPG require a pinentry-program to be set. Set the following to use GNOME 3 pinentry for GNOME Keyring to manage passphrase prompts.
Another option is to force loopback for GPG which should allow the passphrase to be entered in the application.
Renaming a keyring
The display name for a keyring (i.e., the name that appears in Seahorse and from file ) can be changed by changing the value of display-name in the unencrypted keyring file. Keyrings will usually be stored in
/.local/share/keyrings/ with the .keyring file extension.
Automatically change keyring password with user password
Note: This only affects the default keyring.Add password optional pam_gnome_keyring.so to the end of /etc/pam.d/passwd .
-- Prozess 690 (xfwm4) ist abgebrochen worden und
-- ein Speicherabbild wurde generiert.
-- Üblicherweise ist dies ein Hinweis auf einen Programmfehler und sollte
-- als Fehler dem jeweiligen Hersteller gemeldet werden.
Читайте также: