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 have a problem when I tried to use VS 2019 to remote develop on raspberry pi.
The headers file don't copy to the windows machine, even the most elemental like stdio.h
When i tried to force an update in Tools/Options/Cross Plataform/Connection Manager/Remote Headers IntelliSense Manager/Update, the update never suceded and I received differentes errors likes this one :
An error has occurred. Timed out executing command 'realpath -m -L ~', waited for 15000.1469ms. Please see C:\Users\XXXXX\AppData\Local\Temp\vslinux_header_update_log.txt for more information. Please see https://aka.ms/AA23jat for troubleshooting.
Going to the page above doesn't provide any help.
I also tried to manually copy the files in /usr/include from raspberry, but it looks that windows doesn't like the directory structure because some headers appear but others not
I reinstall VS 20199 twice but the error continue
I appreciate your help.
I found the problem and VS was not guilty. The timeout was caused by an intermitent failure in the WiFi, I tried with an eth connection and the problem disappear.
I had installed virtualmin on a RHEL system and a couple of very strange problems have cropped up.
Firstly, the Apache test page now says - powered by CentOS instead of RHEL. All the files and filesystems are intact therefore I am at a loss as to why it would report another version of linux altogether.
Secondly, my sudo access has been overwritten / removed after installation. It just comes up with a message that XXXX (username) does not have sudo access....etc
And lastly, trying to access the virtualmin page over the port 10000 is just returning an "unable to connect" error. [Since I am locked out of using sudo, I am at a loss of how to proceed].
Thank you in advance for your help.
The Apache package we ship is a rebuild of the SRPM from CentOS. The default page is simply an HTML file...it is not "reporting" anything, really, except that you haven't setup any websites yet. On CentOS/RHEL Apache has to be rebuilt in order to support virtual servers in /home when using suexec. So, this is expected behavior and no reason for alarm. We used to ship a custom error page instead (with Virtualmin logo instead of CentOS, but the patch broke a while back and I never got around to fixing it...might go back to that next time we roll an Apache update).
Virtualmin did not touch your sudoers file. That problem is unrelated to the Virtualmin installation. (I wrote the install.sh and the virtualmin-base package; I'm 100% certain your sudoers issue is unrelated to Virtualmin). I don't have any guesses about what went wrong there, or how to fix it if you don't have any way to access the machine as root (rebooting into single user mode would be the right thing if you have hardware access or can get access via a KVM from your hosting provider/colo).
We would need to see the last few dozen lines of the install log to know what went wrong with the Virtualmin installation, and why Webmin failed to start.
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 recently updated to CC.NET 1.5 and I'm now getting some strange exceptions.
On one project I get: -
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: Can't create a character converter from native encoding to 'UTF-8'
This happens when CC is checking a subversion repository for any mods. If I run the actual command line CC says is failing it works and returns an empty XML (there are no mods).
Some other projects also fail to check mods with another "Source control operation failed" exception but no further info. Again the command is an "svn log" which when run from command line works ok.
I'm using subversion 1.4.5 client side and my source repository exists on a separate box than my build server.
Anyone got any ideas?
Have u try to update Svn client ? I doubt it is so simple, but let's check !
Try a svn cleanup
What is your svn config in ccnet ?
What is the build revision of ccnet you are using ? You should try the latest 1.5.x nigthly build, which is very stable for me.
http://ccnetlive.thoughtworks.com/CCNet-builds/1.5.0/
did you try to change the startup parameters of CCService?
Namely, set the "Allow service to interact with desktop" check box on Log On tab.
Also, you may try to use other account than "Local System".
I am not sure, but seems it may fix the issue, since it may be "Local System" account specific issue effect.