Open jankeromnes opened 6 years ago
This seems like a very rare occurrence, so I'll close this bug. Please re-open it if it happens again.
I have the same problem :-( Coincidentally, I'm also using OVH. So maybe OVH is screwing with something. Here are the symptoms...
Same problem... "Failed to write to 'state.settings'" No ability to save layouts. Also the terminals stopped working, no bash.
'nak' utility was terminated by signal SIGKILL
at EventEmitter.
I tried to clone the latest version, same problem.
I'm going to assume this is OVH's fault.
Oh no, apologies for the instability. :neutral_face: And thanks a lot for reporting it, I'll re-open this issue.
Failed to write to 'state.settings'" No ability to save layouts. Also the terminals stopped working, no bash.
This looks like a connectivity problem to the container. Usually a hard-refresh of the tab solves it (temporary connection problem between front-end and back-end), but maybe sometimes it doesn't, which would mean there is a bug with the IDE itself.
'nak' utility was terminated by signal SIGKILL
Hmm, this doesn't look too dramatic (nak
is a search module in Cloud9 IDE, but everything else should work fine without it) but I'm not sure what's killing it.
I suspect this error is related to the Out-Of-Memory errors we've been having lately (when OVH1 uses more than 100% of its 32GB RAM), because in these cases Linux's OOM-killer starts killing processes at random.
Some suggestions:
355a586a7006c061
or a full URL like https://ovh1.janitor.technology/355a586a7006c061/8089/ide.html) as we may be able to fix any hard-refresh-surviving problems by restarting the container (or worst case rebooting the OVH1 sever, which causes a brief ~5-10min outage, so not too bad)/8090/
instead of /8089/ide.html
, i.e. https://ovh1.janitor.technology/355a586a7006c061/8090/ with our previous example). We'll soon add links to these URLs in our UI, but Theia IDE should already work fine.OK guys, after 5 days of pulling out my hair, I found a solution. So maybe OVH on Cloud9 was not the problem.
It turns out, my phone's VPN has a new setting called "killswitch" that was blocking my laptop's VPN. Longer explanation here https://stackoverflow.com/a/50653495/722796
Of course it's possible my laptop's VPN is the solution, but I think more likely, the "killswitch" was somehow mucking up my laptop's Internet connection. Since getting my laptop's VPN running again, everything is running smoother. Like last night I couldn't save a configuration file on my VPS and I tried three different editors with ssh and sshfs, all of them were glitchy, but with my laptop's VPN running properly, I was able to save the file no problem. (Weirdly, I could save a short file last night like "test test test" but could not save a larger file that was just a few pages long!)
So it seems my hotspot works better if it's allowed to pass my laptop's data through without hitting my phone's VPN. Granted, I'm not 100% sure what happened, because I don't know exactly how my phone's hotspot works in conjunction with my phone's VPN, and because I also upgraded my phone and my laptop's OS on the same day, lots of variables. However, that one VPN configuration setting made everything work perfectly again, whereas before everything was working 99% but 1% of everything was breaking.
The Cloud9 IDE in a brand new Servo container on OVH1 started misbehaving today (thanks a lot to @birtles for reporting it and helping troubleshoot it!)
The IDE was basically unusable, Editor and Terminal not working properly, and it was displaying errors like:
and
Opening the DevTools revealed that many requests were getting a
499
error status (on VFS URLs like https://ovh1.janitor.technology/vfs/1/9cbOePWuii5bALJ2?access_token=token).Inspecting the Cloud9 SDK error log with
less /tmp/c9sdk-stderr---supervisor-ejOQPD.log
revealed contiuous VFS errors, likely to be the cause of this malfunction:By searching around, this issue looks similar to https://github.com/npm/npm/issues/10983
We were able to work around this issue by simply creating a new container, which worked fine. Hopefully this was just a temporary bug, associated with that particular Cloud9 SDK version, and we won't see again.
But if you do see this bug again, please comment on this issue.