Just started my development environment after a halfe year to update my app and at first debug
I get the ...
Waiting for application to start debug server
... and it waits forever.
After several kills and trials the issue is gone, but it takes always time and it is frustrating.
I know this issue since several years and there are lots of solution approaches out there which all do not really work.
What is the solution for 2022?
I have a software tool that I have recently upgraded. It is a fresh install and the upgraded product utilizes an Embedded Server. I have allowed the program through my AVG firewall and prior to that before I had AVG through Windows Firewall but still get the same errors. I have shut down the firewall and managed to load the product and get it to work. However this only happens once in every 10 or so attempts and after a reboot, followed by the closing of firewall off. I have attached the messages I get. The "Unable" message comes up first and if I try again the "Error" message comes up.
I would appreciate any guidance or possible reasons you may know of why this is happening.
I have contacted the software producer with a ticket but they have only been able to make a couple of suggestions both of which I tried but failed to solve the problem. I have attached the two messages I get. First Message
Second Message
I have a problem with a bunch (around 50) of classic ASP-Sites on Win2012R2 with Access-Databases, which drives us crazy.
All asp-pages of all sites on this server run smoothly for around 45 seconds, after that period they (all) completely stop responding to any click for 15 to 20 seconds, then this delay disappears again for the next 45 seconds like it never existed before, it re-appears again - and so on. This effect started out of nothing a few weeks ago, after several months without any problems.
Static HTML-pages are not affected, and it seems, even asp-pages without connecting to their database run fine. We, therefore, tried testing to convert from Access to SQLExpress, but this didn't change anything - even the converted site was affected in the same way (so it seems not to be Access).
We then tried to stop all sites in IIS and re-activating just one single site with very few visitors to see if it only appears, when many requests are sent to the server. But the effect still showed up, even after Restarting IIS and even after restarting the whole machine with just one website activated in IIS. It seems to be completely independent from the number of effects, just like the server (rather: the asp-engine of IIS) being busy with itself in a periodical pattern.
What we can see in performace monitor (see screenshot): while requests/sec goes down to 0 at some moment, when the effect starts, the number of requests executed continuosly accumultes from a normal level (which looks "logical" to me, but only describes the effect, not justifies, where it comes from). A few seconds before the effect vanishes, request/sec again grow and these counters revert to normal values.
We had a similar problem a year ago on a Windows 2008-Server, where the sites ran without any problems for several years and then it started out of nothing. After testing some of the sites on a server of another hoster, we found out, the problems didn't appear on his server with Windows 2012 R2 (and still don't for a full year, while hosting 3 of our sites there). At another hosters virtual Windows 2012R2-Server we have another single site hosted with more traffic than most of our others and even there the problem didn't appear since a full year now. So we our hoster switched over to WinServer2012R2 and - bingo - all the problems were gone. All sites performed like a charm again from that moment on without changing anything but the OS.
We then stopped investigating the issue, thinking the problem relates to the OS. But around 9 months later, it re-appeared and after hours and hours of investigating we have no idea, what to search for and what to do (beside of moving all our sites to the other hosters server, which isn't a real solution to the problem and we cannot guarantee, the effect will not re-appear on this machine sometimes in the future).
I definitively found a solution by myself, but in a totally random way. After weeks of searching for a solution to the problem, I worked on cleaning up the server's hard disk and deleted all files in Windows/temp-folder (> 18.000 files!). And since this moment (4 days ago), the described response lag never showed up any more! But a small bunch of new .tmp-files were created in the folder.
My theory is: maybe every time a user visits one of the websites (which opens connections to its Access database, causing a .ldb-file in the database folder), a randomly(?) named .tmp-file (like: jet12f0.tmp) is created in Windows/temp folder in parallel. These files are "normally" deleted again, as database connection closes and the .ldb disappears. Maybe some of the connections are not closed correctly, therefore the corresponding .tmp-file in the Windows/temp folder resides there as an "orphan", literally forever. As time goes by, the folder fills up with these orphaned files. And then it comes, that a new .tmp-file should be generated, but with a name of a still existing "orphaned" .tmp-file. This now causes the server to stop all actions, because it is not possible to establish the new file, named like an existing. After 15 to 20 seconds the conflict is solved by some mechanism (unknown to me) and all runs perfect again, until the next conflict arises around 45 seconds later. And so on...
I must assume: this is only a "amateur" theory, I'm not a server "Guru".
Cleaning up this temp-folder from time to time seems to prevent the server from getting into this situation, because there are no file/naming conflicts.
I agree: The real solution would be finding the problem in the code (if there is one), but we can live with that situation, comparing the effort to find the problem with just cleaning up the temp-folder once in a month or so ;-)
I am facing a CPU overload issue due to a nodejs application that I am running in a remote Ubuntu 16.04 LTS virtual machine. I am using PM2 to schedule my nodejs application as a service.
Initially when the nodejs application is launched, the CPU load remain quite low; about 30% at most. Then slowly I find the CPU load going up till it gets to 100%. This nodejs application is polling a stock website for new information on a stock and then does some calculations and then repeats after 5 minutes. I dont see how its causing this overload on the CPU.
I notice that my 1 nodejs application shows up as 6 different processes in HTOP command. Not sure if this normal or how to fix this. Any help would be highly appreciated.
Thanks
Regards,
Adeel
Thanks, Gerard. Your reply helped solve the problem. Turns out guardian.js was not exiting and just opening up new processes till it overloaded the system.
I'm not well versed with xymon troubleshooting and the guy that normally supports xymon is on leave. So I need a pointer or two on where to look for the problem.
We have a xymon ver 4.3.26 server monitoring roughly 1400 systems normally quite well. We patched about 200 systems last night and, after all said and done, about 34 of these systems are showing purple on the 'all non-green' page.
This has happened before and the xymon server will 'catch up' after a time. However, 12 hours later, these 34 are still showing purple for all tests.
I've tried restarting the xymon services on the client and, when that didn't produce results, restarted services on the server - still to no effect.
I've found the logs under /var/logs/xymon; but, nothing in those look untoward. Some entries about garbled messages from unrelated hosts that have apparently been going on forever so unrelated to this issue.
So, long way to a short question: how do I find out why clients are not able to report? Is there a way to test connectivity or some other logs that show connectivity issues?
After much poking about, I finally found /var/lib/xymon/tmp/xymond.chk.
service xymon stop
cp xymond.chk xymond.chk.161222 && > xymond.chk
service xymon start
All statuses reset. Had to go back and re-disable some tests but everything's working again. I have the feeling I took a small thermonuclear device to a fly; but, the fly's dead, so ...