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
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
I am no longer able to run node from the git bash terminal. It works from Git CMD and the standard windows CLI. If I try to run a file (e.g. node index.js) or even just start node via node, I go back to the input prompt except now I can't see any of my character inputs.
This is not a result of PATH not being set, as where node gives me C:\Program Files\nodejs\node.exe and which node gives me /c/Program Files/nodejs/node and echo $PATH does have /c/Program Files/nodejs included.
If I type another command (such as ls), it actually will work even though I will continue to not be able to see my input.
I think this problem arose after the latest Windows 10 OS update was pushed to my system (10.0.17763). I've tried reinstalling Git for Windows and Node, and neither have resolved the issue. I can't find any other settings that might be affecting this.
Using Git CMD or Windows CLI is a workaround, but neither of those have a "Git Bash Here" option, which is the #1 thing I want this for. It is also nice that I get the visual indication of branch in Git Bash where I do not get that with Git CMD or the Windows CLI.
I don't need or want to use Git GUI, and besides that won't allow me to run local node files which I need to do for testing.
Does anyone have any ideas on how I can get Git Bash working with node again?
UPDATE: By running stty -a after node fails, I see that echo has flipped to -echo, which is why I can't see the input anymore. But that doesn't explain why node isn't loading and echo is getting turned off. Hoping that gives someone some additional context to figure out what's going on here. brkint, icrnl, ixon, opost, isig, and icanon are also getting flipped to the - versions after attempting to run node.
There are 2 possible workarounds (based on what your problem is) that I have tried-
Enter node first of all:
1) Try typing in reset and hit enter. You may not be able to see the input logging in, in the bash terminal window, but it works after that.
2) Or try typing any random alphabet and hit enter(again you won't see it on the screen),it will throw a 'command not found' error but you will have node working after this.
I am afraid these aren't exactly proper fixes, but they get the job done.
More information can be found here: https://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened/172747#172747
I am trying to Install Cygwin 64 bit on a Windows 2012R2 (64 bit).
Downloading and initial setup went through but when it reached man-db (/etc/postinstall/man-db) the setup hangs
and remains so forever. I waited more than 1.5 Hours but still no progress.
I checked log file in /var/log/setup.log which has following contents.
Updating index cache for path `/usr/share/man/man1'. Wait...
Processing manual pages under /usr/share/man...
/usr/bin/mandb: warning: /usr/share/man/man1/col.1.gz: whatis parse for col(1) failed
/usr/bin/mandb: warning: /usr/share/man/man1/imv.1 is a dangling symlink
/usr/bin/mandb: iconv_open ("UTF-8//IGNORE", "utf8"): Invalid argument
/usr/bin/mandb: warning: /usr/share/man/man1/mc.1.gz: whatis parse for mc(1) failed
I am not sure if I should cancel and start again. Will this setup come out of this stage with at least some error?
Did anyone install 64 bit Cygwin and got this error ?
Please help
Happens to me often. I was setting up 8 servers this week and it happened to 3 of them. Waited many hours and it is still would not finish. Sometimes the re-installation works, some it does not. So I have resorted to kill the mandb.exe process and that allows the installer to finish normally. So far I have found no side effects of doing so.
After waiting for more than 3 hours, I decided to cancel the setup. Then I tried a reinstall, following the steps exactly as in the first install. I did not add or remove any packages. The already selected packages in the first attempt were recognized as installed. This time, the setup stopped at the above step (man-db) briefly and then completed the installation. No errors. So, re-installation solved my problem.
Late to the party, but —
When mandb.exe hung, I killed its parent bash.exe via Task Manager and the installation completed.
I then killed mandb.exe in Task Manager, since it was still running.
I then opened a Cygwin shell and ran mandb -cds. -c recreates the index, -d prints messages (so you can actually tell it's doing something constructive!) and -s suppresses checking for orphaned formatted manual pages ("stray cats").
As I write this, mandb is still chugging along, three or four hours later, with plenty yet to go.
So I'll remember to file a bug report later :) , I did notice one oddity during the mandb run:
mandb: /usr/share/man/man3/jN.3 is self referencing
mandb: warning: /usr/share/man/man3/jnf.3.gz: bad symlink or ROFF `.so' request
I've been struggling with the same problem today until I realised that moving the main Cygwin setup window revealed a popup complaining about "can't open (null) for reading: no such file"
This happens multiple times in a (re)install
cygwin64 had been running great on my Windows 7 system for several months. After rebooting this morning, it appeared to be inexplicably broken. When I started a new mintty session, rather than presenting a window with my familiar bash prompt, I got a blank window entitled -sh.exe. Sure enough, despite the lack of any sort of prompt, it was a shell window. ls, pwd, cd, and other commands worked, but my environment was a mess. Aside from the lack of a prompt, my home directory, path, and other things were messed up.
I tried the normal things. I reran cygwin setup to no avail. I completely uninstalled and reinstalled cygwin, again with no discernible effect. I rebooted a number of times during all these tries. What could cause cygwin to suddenly begin behaving so badly?
I had similar issues after installing IBM InfoSphere DataStage, which causes Cygwin to misbehave because it is setting several Windows environment that are inherited by Cygwin, and are crucial to Mintty and the shell. These variables are: SHELL, TERM, TERMCAP, and TERMINFO.
I modified my Mintty shortcut to contain the following target, and this fixed the issues:
C:\cygwin\bin\mintty.exe /bin/env -u SHELL -u TERMCAP -u TERMINFO - TERM=xterm-256color HOME=/home/username /bin/bash -i -l
The -u options are unsetting those variables, and then I'm explicitly setting TERM and HOME (make sure to use your home directory instead of /home/username).
I also had to copy my ~/.minttyrc file to /etc/minttyrc so that mintty would see it.
After digging around, I noticed that the sh.exe that was running was not in /cygwin64/bin, but was instead in \Program Files (x86)\MKS Toolkit. I did not recall installing MKS, but the date on this directory was from the previous day. The only thing I'd recently installed was the IBM InfoSphere DataStage client. It turns out, InfoSphere not only installs the MKS Toolkit, it prepends it to a number of environment variables, totally hosing cygwin.
All of the sudden svn stopped working in cygwin installation on windows xp. when I execute svn binary, nothing happens, svn process does not even show up in the Task Manager. I've reinstalled svn but it did not help (the last resort would be to uninstall cygwin itself). Everything else in cygwin works fine: awk,python,sed,more,less,tail and etc.
here is what is happening ...
mt#s022 ~
$ which svn
/usr/bin/svn
mt#s022 ~
$ svn --version
mt#s022 ~
$ svn status
mt#s022 ~
$ svn info
mt#s022 ~
$
Same problem as well.
No solution, but here's an interesting thing: For me, "curl" and "wget" are also broken in exactly the same way. This makes me wonder if it is one of the underlying networking libraries (libcurl, or similar) that is at the root of the problem (total guess).
EDIT: I have solved this problem. The problem turned out to be what seems to have been a "bad" version of openssl. I used the Cygwin setup program to "Reinstall" OpenSSL. The version number in setup is now "0.9.8n" which seems to have replaced "0.9.8", which I suspect was a bad version that was temporarily distributed, so if you were unlucky enough to update at the wrong time then this is what you got. The new version doesn't seem to be installed automatically just by updating normally. I'm guessing 0.9.8 is seen as the same version as 0.9.8n.
In case this doesn't solve it for others: the key insight was gained by launching svn.exe from Windows Explorer. While it exits silently when run from the bash command line, when run from Windows Explorer it pops up a window complaining: "the procedure entry point pqueue_size could not be located in the dynamic link library cygcrypto-0.9.8.dll". This allowed me to identify OpenSSL as the culprit. The same might be possible for other problems that manifest as commands silently exiting when run from the bash terminal.
This is what I did:
net stop sshd (this is optional)
remove /usr/bin/cygwin1.dll
remove /usr/bin/cygcrypto-0.9.8.dll
run cygwin-setup
reinstall cygwin-base
Hope this helps.
Ran into this problem. It seemed to have started when I added one small package and left everything else as keep. Solution that worked: remove cygwin1.dll, run cygwin's setup.exe, keep everything except base->cygwin. Updating that updated cygwin1.dll, and all was fine again.
I had same issue.
I followed the suggestion above and tried to launch svn from the windows explorer and it turned out that I had a problem with cygwin1.dll itself.
Doing a reinstall of the cygwin package solved my problem
I had the same problem and upgrading/reinstalling the cygwin base classes didn't help me neither...
Until I disabled the "CYGWIN sshd" service.
Therefore, if you run the Cygwin sshd process, stop it first, before upgrading Cygwin.
Good luck!