I'm running cygwin64 on Win10-64bit and have an X11 server running with a dbus-daemon. The X11 server is run rootless using startxwin. I'm not running anything gnome or kde based (because of the problem below).
I get long pause (30+ sec) and an error like:
(process:1199): GLib-GIO-WARNING **: Problems looking up entry in keyring: Error opening keyring “/cygdrive/c/Users/dc5/.dbus-keyrings/org_freedesktop_general” for reading: Failed to open file “/cygdrive/c/Users/dc5/.dbus-keyrings/org_freedesktop_general”: No such file or directory
This happens whenever any modern X11 app tries to start: emacs-X11, gnome-terminal, etc.
I tried creating a file there, but then it complains that it isn't valid and there is still the long hang.
It isn't clear to me why anything is trying to open a keyring. Sometimes it triggers at weird times. I just hit it loading the magit package under emacs-win32.
How can I either create a keyring or make it not try to find one?
Related
I have read the guindance that the keyring package has in its project for headless linux systems.
So the main recommendation is to install the gnome-keyring package in order to work with the Secret Service Backend.
sudo apt install gnome-keyring
Then, as I already have the dbus package installed I just run:
dbus-run-session -- sh
But, as I am in WSL 2 I get a weird prompt, it seems that PS1 is not parsed and I get something like this:
\[\e]0;\u#\h: \w\a\]\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$
In a normal Debian or Ubuntu instance I would get $
I send the password to unlock the keyring
echo 'db' | gnome-keyring-daemon --unlock
I also tried to enter the password manually through stdin as this answer points out, with the same result:
gnome-keyring-daemon --unlock
Now the guide says "run your application in the same D-Bus session as the daemon". I don't know if I need to do something special to achieve that. I just run python after entering the password.
$ python
>>> import keyring
>>> keyring.get_keyring()
<keyring.backends.SecretService.Keyring object at 0x7f383b89f220>
>>> keyring.set_password("system", "username", "password")
But at this point I get this error:
dbus-daemon[9337]: [session uid=1000 pid=9337] Activating service name='org.freedesktop.secrets' requested by ':1.4' (uid=1000 pid=9339 comm="python ")
GNOME_KEYRING_CONTROL=/home/db/.cache/keyring-TPE3M1
dbus-daemon[9337]: [session uid=1000 pid=9337] Successfully activated service 'org.freedesktop.secrets'
dbus-daemon[9337]: [session uid=1000 pid=9337] Activating service name='org.gnome.keyring.SystemPrompter' requested by ':1.5' (uid=1000 pid=9356 comm="/usr/bin/gnome-keyring-daemon --start --foreground")
Unable to init server: Could not connect: Connection refused
(gcr-prompter:9364): Gtk-WARNING **: 09:36:04.690: cannot open display:
dbus-daemon[9337]: [session uid=1000 pid=9337] Activated service 'org.gnome.keyring.SystemPrompter' failed: Process org.gnome.keyring.SystemPrompter exited with status 1
** (gnome-keyring-daemon:9356): WARNING **: 09:36:04.701: couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.keyring.SystemPrompter exited with status 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/path/to/env/lib/python3.9/site-packages/keyring/core.py", line 60, in set_password
get_keyring().set_password(service_name, username, password)
File "/path/to/env/lib/python3.9/site-packages/keyring/backends/SecretService.py", line 87, in set_password
collection = self.get_preferred_collection()
File "/path/to/env/lib/python3.9/site-packages/keyring/backends/SecretService.py", line 67, in get_preferred_collection
raise KeyringLocked("Failed to unlock the collection!")
keyring.errors.KeyringLocked: Failed to unlock the collection!
And the processes tree look like this
I also tried with
dbus-run-session -- bash
With the same result
Possible WSL 2 Issue
I also found an issue on WSL2 project where "jaraco" says that the guidance that I followed may give some hints, but I could not get it to work.
Alternative Backend
I tried with other backend as well, though in some places they say that this backend is not recommendable:
“alternate”, possibly-insecure backends, originally part of the core package, but available for opt-in"
pip install keyrings.alt
With similar result. The keyring backend was different:
>>> keyring.get_keyring()
<keyring.backends.chainer.ChainerBackend object at 0x7ffbad5fd040>
Any alternative or recommendation? Am I missing some step? Is this possible to make in WSL 2? I think I will try in a debian machine directly to check if it is a problem of WSL or all Debian headless distros. Anybody make it work on Debian without Gnome desktop installed?
The next step would be to automate all the process, but first I need to get this to work
Update
Well, I can confirm that in a virtual machine on Debian 11.3 works fine. So it must be something to do with WSL 2
Update 2
Ah, I have just realized that I had installed the WSL2, but my Debian System was in WSL so I had to update it to WSL2 with the following instruction. Anyway, I think the behaviour, in this case would be the same.
wsl --set-version Debian 2
Note that I have been able to get this to work (WSL2, Debian Bullseye, python3, gnome-keyring, Windows 10). I can understand parts of why it may not be working for you, but there are some minor differences in the errors you are seeing from what I can reproduce (when I try to break it). We'll come back to those if we need to, but let me go through what I've tried successfully so far.
But, as I am in WSL 2 I get a weird prompt
First, I think this is an orthogonal issue, but perhaps not. I always suspect startup configuration files for this type of weirdness, so I would try eliminating those from the equation:
dbus-run-session -- bash --noprofile --norc
If the prompt looks normal when running that, I'd look to ~/.profile since it sounds like it it happens both Bash and Dash (sh) for you and Dash doesn't have an rc file.
Again, I'm assuming that's not the problem with the keyring, but it doesn't hurt to eliminate it as a potential contributor.
As for the main keyring problem, that, I believe, is because:
Gnome Keyring is attempting to ask for a password. It does this with a graphical password prompt, which fails because ...
You are running Windows 10 without an X server, or if you are running an X server, then the DISPLAY variable is "lost". That's the cannot open display error in the trace. If you were on Windows 11, the graphical prompt would display. You could also configure Windows 10 WSL to use a third-party X server like VcXsrv. Or you could run with Xrdp. See this Super User question (and others) for more info.
Of course, that would no longer count as "headless", which is your question. So we need to figure out why gnome-keyring is asking for a password. I can think of at least possible three reasons, but there may be others:
The default collection (keyring) doesn't exist yet. I'm fairly sure that's not the case for you, since it should have been created when you ran the --unlock. Of course, you can verify this by checking ~/.local/share/keyrings.
gnome-keyring-daemon hasn't yet been started, and needs the keyring password. Again, you've clearly run that here. You've done the right thing by running the dbus-run-session first, then inside that session, run the --unlock. You can, of course, verify that it is running with a ps -efH or similar.
The password that was passed via --unlock is wrong.
So with the first two eliminated, we're left with the assumption there's an issue with the unlock password. If you created the collection with the initial --unlock, then the first password you used should be the one set on the collection.
There are some "gotchas" here. First, contrary to what the answer you linked says, I'm convinced that the newline is added to the password. If you somehow initially set the password without a newline, you'd need to unlock it with echo -n. E.g.:
echo -n 'db' | gnome-keyring-daemon --unlock
Second, it doesn't sound like this was the case for you, but if you create the keyring through the normal frontend, then it appears to me that the password may be salted. I have not been able to use gnome-keyring-daemon --unlock (in any of its forms) to unlock a collection where the password was entered through the graphical prompt. To clarify:
If I initially create the keyring via gnome-keyring-daemon --unlock, then I can unlock it either through the GUI askpass program that it uses (on Windows 11 or with a Windows 10 VcXsrv installation), but ...
If I initially create the keyring via an initial access of it which prompts for the password through the GUI, then I can subsequently only unlock it through the GUI. I can no longer use gnome-keyring-daemon --unlock.
Assuming this is a new keyring in WSL2, then my advice would be to remove it and try again:
dbus-run-session -- bash --noprofile --norc
# Back them up first if you'd like
rm -rf ~/.local/share/keyrings
echo -n 'db' | gnome-keyring-daemon --unlock
python3
Note that you can test the keyring module directly from the shell via:
python3 -m keyring set system username
# Will prompt for the secret
python3 -m keyring get system username
# Should return the secret
If things are working from there, they'll work from your code. If it fails, it should do so with the same error at least. This might save some time in troubleshooting if this doesn't work.
I've been getting the following error from the source control plugin on VSCode "Extension host terminated unexpectedly".
If I check the logs I see the following info: "EMFILE too many open files."
I've already tried a few things like:
Remove and install VSCode again.
Increase the number of opened files on Ubuntu.
Install Watchmen
Unfortunately, none of this solved the problem... Any suggestions?
I'm very newby in node.js world, and I'm doing the first steps, but I can't step forward because when I try to do any operation from node.js command prompt in Windows 10, the node.js console is opened and closed very fast and I haven't time enough to read the errors or anything that is written on console. Is there any way to configure node.js to stop the console before to quit it? Or to execute on same opened Node.js command prompt.
For example I'm unable to read the version of different modules installed, the console opens and closes very fast.
I've tried windows standard command line, node.js command prompt, an application called cmder, and in all instructions related to node it throws a new window with node.exe. If the command waits user prompt the console (node.exe) is paused, but when I try an application that only log some data (like npm --version) I can't see the result, because after log, the console is closed.
Some time ago, I've tried in Windows 7, and I remember that the node prompt was opened on the same command console. I don't know if it's the SO, or the node.js version (4.4.4 LTS).
Ouch! I've found the solution, I was trying to avoid the annoying "run as administrator" dialog and I've configured the node application properties checking the flag "Compatibility > Run This Program As An Administrator". That was the source of all my problems!
Hope it helps anyone!
I recently reinstalled Cygwin on my computer in order to get access to several command line elements that I was missing. I have never had previous difficulty with Cygwin, but after this reinstallation, an error message continues to appear after (almost) each command entered. For instance:
-bash-4.1$ wc m1.txt
3 [main] bash 2216 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x38D000)
-bash: fork: retry: Resource temporarily unavailable
2013930 4027950 74968256 m1.txt
Generally, the command still runs (as seen above), but not always. Occasionally, the 'error' message occurs several times in a row (the initial number "3" will then change to a "4" or "2", notably if I start a second Cygwin window.
Also, as soon as I start up Cygwin, I get the following message before the prompt:
3 [main] bash 6140 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x36D000)
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash-4.1$
At the moment, I am debating whether to uninstall/reinstall Cygwin again or just live with the error messages, but I was curious if there might be an issue that I am unaware of.
(assuming Cygwin is installed at C:\Cygwin):
Open Task Manager and close any processes that look to be Cygwin related.
Open C:\Cygwin\bin in Windows Explorer
Verify that dash.exe, ash.exe, rebase.exe, and rebaseall exist in this folder
If any of them are missing, re-run Cygwin setup and select the dash, ash, and rebase packages
right-click your C:\Cygwin folder, uncheck Read-only (if its checked), and press OK.
When an error about not being able to switch some files comes up, select "Ignore All". Wait for this process to complete.
Browse to C:\Cygwin\bin in Windows Explorer
Right click dash.exe and click "Run as Administrator". A command Prompt should appear with nothing but a $
Type /usr/bin/rebaseall -v, hit enter, and wait for the process to complete.
If you get errors about Cygwin processes running, try Step 1 again. If that still doesn't work, Restart your computer into safe mode and try these steps again.
A commenter noted that, depending on your settings, you may have to type cd /usr/bin && ./rebaseall -v instead.
Try opening Cygwin again.
This process worked for me. I hope it works for you guys too.
Source: http://cygwin.wikia.com/wiki/Rebaseall
I would like to add the following to the above answers, as it is what I had to do after reinstalling Cygwin:
Navigate to the "/usr/bin" directory (usually, C:\cygwin\bin) and right click, Run as Administrator the file: dash.exe
Then, at the $ prompt type the following, hitting enter after each line:
cd /usr/bin/
/usr/bin/peflags * -d 1
/usr/bin/rebaseall -v
What it does is, it marks the dll's as "rebase-able," and then rebases them. You have to have peflags.exe in addition to the above files (in previous answers). You may have to restart windows after doing this and you will definitely need to make sure that there are no processes nor services belonging to cygwin running. (Use task manager, kill any related processes, and then under the services tab look for any service starting with CYG and stop it.)
After doing this, I was able to get cygwin to run without any errors about dll's being loaded to the wrong addresses aka fork errors, etc.
I hope that this helps others, as it was a pain to find.
SOURCE: http://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
and the rebase README file.
To add on to other answers here, we ran into the same issue but could not run the rebase command from the ash or dash shell. However, when launching the command from the Windows cmd shell, the following worked.
cmd /c "C:\cygwin64\bin\ash.exe /usr/rebaseall -v"
-v is to get verbose output
I found another information here :
http://cygwin.com/ml/cygwin/2014-02/msg00531.html
You have to delete the database at
/etc/rebase.db* and do in a "ash" windows :
peflags * -d 1
rebaseall
It works for me on 2 servers.
I solved this problem by restarting my computer. Probably installed a driver update and kept using sleep instead of shutting down.
Experienced the same issue when loading Cygwin with cygiconv-2.dll forking and not loading successfully in the Cygwin terminal, but after turning off my AntiVirus (it was specifically Ad-aware), the issue resolved, and Cygwin worked properly.
In case you are using babun's Cygwin, after rebaseall, try launching Cygwin by executing .babun\cygwin\cygwin.bat in a Windows command prompt or Windows explorer.
This works for me (while launching babun's default console - mintty results in fork error).
I had the error on win10 and i was trying to rebase to c: before install.
then i saw that the installer was installing it instead to c:/Users/myuser
so i was coping all files from c:/Users/myuser to c:.badun
and then restart plus open badun.bat
not shure if this was wise its now duplicated XD... but then it worked again.
Rebaseing didn't help in my case. In addition to what other people suggested, I noticed that reducing the length of PATH environment variable fixed the issue for me (and for other people as well as can be seen from this answer).
This issue is intermittent in nature & I found this issue when there is network is too slow to connect to remote machine on AWS.... I have Shell script that runs through Gitbash shell & it connects to AWS EC2 instance with ssh..... Most of the time, it ran correctly but 2 out 100 times it get into this issue bash: fork: retry: Resource temporarily unavailable .... Killing the MSYS2 terminal from task manager helps to overcome with this issue....
Negative side is you need to run the scripts from the beginning...
I had the same issue on Windows 10 and the mobaxterm app (which uses cygwin) and I tried all of answers listed here however for me, the solution was to simply delete the "CryptoPro CSP" application.
I started facing this problem after upgrading to windows 10. As of now I do not see that any of the above method working.
What I am noticing is that if you start cygwin with admin right (right click and say "run as admin") then it works fine.
Or you open cmd as administrator and then launch cygwin from there, then also it runs fine.
Just reinstall cygwin and select TCL and activate EXPECT
I have installed firewatir 1.8.0, jssh 0.9 addon.
Do I need to open the firefox browser manually from the command prompt with -jssh extension every time I want to run the tests in firefox?
When I try to run the tests without manually opening the browser I am getting the following error:
C:/Ruby192/lib/ruby/gems/1.9.1/gems/firewatir-1.8.0/lib/firewatir/firefox.rb:156:in `rescue in set_defaults': Unable to connect to machine : 127.0.0.1 on port 9997. Make sure that JSSh is properly installed and Firefox is running with '-jssh' option(Watir::Exception::UnableToStartJSShException)
Also I tried running the tests by changing the path from "C:\Program Files\Mozilla Firefox\firefox.exe" to "C:\Program Files\Mozilla Firefox\firefox.exe" -jssh in the Target text box of the Mozilla Firefox Properties window.
Yes see here fore more info
You will need to open Firefox using acommand line argument to get FireWatir to recognize jssh. To do this, open your command prompt, or a terminal, and run:
firefox.exe -jssh
or
./firefox-bin -jssh
from the appropriate folder, depending on your platform.
i'd also encourage you to look at watir-webdriver as an alternative. Ongoing development of JSSH/firewatir is doubtful for Firefox 4 and beyond. Watir-webdriver is looking like the way to go, especially if you're just starting out.
When running on my Mac the WATIR test starts Firefox with the JSSH automatically, but usually this takes longer to start than the connection timeout in the script.
So it is easier to start it manually before running the scripts.