Krydos

It looks like it's working again now. Having one nameserver down generally isn't going to affect the uptime of anyone's website, as long as at least one nameserver is up. The reason for two or more nameservers is to have 100% uptime of a least one of them being up. Having a nameserver down just means that the working nameserver is going to have to work twice as hard to answer all the requests. One of the nameservers going down won't make your site redirect to an old server, unless there is some caching issue going on and you just recently changed to our nameservers. The old wrong cached value should expire on it's own within a day or so. Usually less.

Closing due to inactivity.

Unarchived. Your username had to be changed to nazabal2.

Do you mean Tk::Chart (1.22)

Deployed.

Done. You should now be able to log in and your website should start working within 2 hours.

Your account was archived because you haven't logged in for quite a while. We have a limited amount of space on our servers, and occasionally we have to remove the unused accounts to make space for new users. To prevent your account from becoming archived again please remember to log in at https://www.heliohost.org/login/ at least once every 30 days. Unarchiving...

Yes, reply to this post when you're certain the issue is fixed and I will remove the block preventing your account from deploying a .war. Once the block is removed you'll be able to use the java page in cpanel to deploy as usual.

Please clear your cache.

For the past month or so your .war has been crashing Tomcat on Tommy for everyone. You've caused a very considerable amount of downtime for everyone who uses java on Tommy. The first few times I just assumed was a fluke, and then I upgraded Tomcat to version 9.0 hoping it would solve the issue. After it continued crashing for something like the 10th time I actually put in the effort to troubleshoot the problem. What would happen is after a day or two of running without a restart Tomcat would just randomly go completely unresponsive. It wouldn't even shut down cleanly using bin/shutdown.sh. So I'd have to send it a signal 9 and restart it. The log files complained about running out of memory, but after some research I found that it was more likely it was running out of available threads. I doubled the number of available threads to Tomcat, and it seemed to help. It would take roughly twice as long for Tomcat to crash, but it was still crashing. Then I went through the very tedious task of analyzing the stack trace for thousands of active threads on Tomcat that had been running for over a day, but hadn't crashed entirely yet. What I found was that your .war is creating thousands of threads named pool-512-thread2, etc. and when the system reaches its maximum it shuts down. Just to be absolutely sure it was you causing the issue I undeployed your .war and Tomcat has been running for quite a while now, and the thread count is about 60 rather than several thousand. Please test your .war thoroughly on your home computer to make sure you have fixed the thread bug, and when you're confident you have it fixed let us know and I'll remove the block that prevents your .war from being deployed.

As long as the scripts don't cause a lot of load they should be fine. If you read the link that you posted there is actually 3 scripts. One to start the script that you access with a browser, one to end the script that you access with a browser, and a loop script that you don't access in a browser. If you run the loop.py directly you'll get a 500 error when you browser closes, times out, or the http process kills it, etc. Also I don't see a shebang on your script that you posted. Did you just omit that?

As long as everything goes well it should be installed tomorrow https://www.helionet.org/index/topic/34716-tommy-django-upgrade/

Wow, thanks a ton! Here's the infobox image I used on my article https://en.wikipedia.org/wiki/User:Krydos/sandbox#/media/File:HelioHost_logo.png

There you go https://krydos.heliohost.org/cgi-bin/modules36.py There is no such module named pkg-resources. It's actually a bug in Ubuntu https://stackoverflow.com/a/40167445/2336864

http://arkham19.heliohost.org/mb/ is working for me. Where do you see that error?

What went wrong with the deletion script? I sent you an email to confirm you're the owner of that account. Reply and I'll delete it.

The error the deployment was giving was 13-Dec-2018 04:19:01.793 SEVERE [http-nio-8080-exec-26] com.sun.jersey.spi.container.ContainerResponse.mapMappableContainerException The exception contained within MappableContainerException could not be mapped to a response, re-throwing to the HTTP container java.lang.OutOfMemoryError: unable to create new native thread I restarted Tomcat and it deployed fine after that. I suspect someone else's .war is crashing the system by using up too many threads or memory. This is the same issue we had on Tomcat 8.5. When I have some time I'll try to figure out who.

You can install your own certificate though https://wiki.helionet.org/Installing_a_Let%27s_Encrypt_SSL_Certificate

It might have been a high load issue. Since Johnny, the server that you picked, is so overcrowded the load can get really high sometimes.

Those look like local includes to me. Have you checked to make sure those included files exist?

The phpmyadmin on your account is working for me. Has the issue resolved itself? https://johnny.heliohost.org:2083/frontend/paper_lantern/sql/PhpMyAdmin.html

I'm sorry. For some reason when I was writing that earlier I read it as allow_url_fopen not allow_url_include. We allow a lot of easily hacked software, most notably wordpress, run on our servers, and allowing hackers to include malicious code hosted on another server is a security risk. We can control our own servers pretty well, but allowing users to execute code on some other server that may or may not have any security could be a problem if the remote code is changed by a hacker. Why do you need to include remote code? Why not just upload it to our server and include it locally?

PHP errors are off by default. I had to recompile a few versions of php a while back, and simply forgot to turn errors back on.

Does it work now?

It's currently set to GPCS which is default. The E is a performance hit to list in this directive, and you can access it via the getenv() function anyways if you really need it which most people don't. I think you can just set it via the curl CURLAUTH_GSSNEGOTIATE option. That's a pretty obscure one. This would require compiling curl from source which would undoubtedly break other things. I prefer to keep everything supported through the package manager if at all possible. Cpanel disables this by default for, what I assume is, performance increases. Cpanel disables this by default for, what I assume is, performance increases. This is a security risk. Cookie based sessions are more secure than URL based sessions. I think this is already set. I think this is already set. I'm not sure what this is supposed to mean. The default value is "a=href,area=href,frame=src,input=src,form=fakeentry". This option is related to the URL sessions that I listed above as being a security risk. Overall, I really think that whatever software you're trying to run is going to require a vps if it really needs all of these insecure settings. Luckily for you we provide those.