Piotr GRD

If the whole physical server will have troubles - obviously both virtual servers (Cody and Johnny) will be affected. But if only the one virtual server have troubles the other one may be not affected at all or in very limited way.

@ anush Cody is a virtual server with HelioHost.org and HelioNet.org. And nameserver ns2. If these works then djbob already did restart it. It's on the same physical server with another virtual one - Johnny. Stevie is a separate physical machine.

It's not "down", it still works, but the responces through HTTP on port 80 takes a lot of time (so usually browser gave up and say that the connection times out). n30n posted about it ~24 hours ago already. http://www.helionet.org/index/topic/11375-stevies-http-whats-wrong/ And it looks that the problem started (on a smaller scale) in last Thursday or Friday already, in Sunday it was much more significant, and since Tuesday (yesterday) problem is very significant.

Don't you afraid that some other people may have files named .*core.*, too? ; ) I would use more detailed regular expression, ie.: ^core\.[0-9]+$

FTP server will always convert new lines for you to the standard used in the system on the server if you send the file in txt mode. So in example if on Windows you use - as xaav wrote - CR+LF, then it will be converted to the LF on Unix system. And when you download it back again it is not converted back by your FTP client so you can notice that file has been change. If you really want to you can avoid it and send all the files in binary mode (you can set it in FileZilla), so nothing will be converted, file will be sent as is. However as this makes no difference in example in PHP or pure HTML or even in .htaccess files, but for such language as Python it may be a problem if you'll use different new line characters (I'm not sure, though). So as xaav already wrote - you may want to use LF for new lines ("Unix format" in Notepad++ options).

At the moment HelioHost nameservers do not have any information about your domain name. You can check it with ie. this utility: http://heliohost.grd...pl/dns-checker/ Did you add your domain name in HelioHost's cPanel? Either as the main domain name while creating the account OR as the add-on or parked domain. If you did - make sure you didn't misstype the domain name. Wait until ~01:00 PST / ~09:00 UTC - this is the time when scheduled synchronisation of DNS entries on HelioHost nameservers should be completed (sometimes these nameservers fails, so such synchronisation is scheduled every 24 hours after 8 UTC / midnight PST).

Yes, error 500 and for PHP scripts only. Static content like *.css or *.js and images is fine. And if someone will have doubts about it: Yes, it's going through CloudFlare, but it doesn't matter. When I call it directly from Stevie it's still error 500 for PHP and it's fine for static content.

Advantage of using PHP in this case is that that I was able to spot just by looking at my graphs that there is something wrong with the server. At least until the time when I'll enhance range of monitoring (HTML / PHP / PHP+MySQL, just like I do monitor on some of the other webhosts) I leave it as is. Additionally... I would need to start to learn Perl, before. ; ) I didn't check this but does the Perl scripts worked at the time when PHP didn't?

As I wrote in here: http://www.helionet....ipts-on-stevie/ PHP scripts - MySQL powered or not, doesn't matter - return error 500 since ~06:08 UTC (~22:08 PST). There were such cases in the past already. Because of this I am not able to get the informations about server load from the server. I need a working PHP script on Stevie that will report it to me, but this script doesn't work and only return error 500. Similar thing you can notice when all the accounts return "account queued" page (which happend from time to time, too) - in such case again, I can not get the informations about server load from the server so server load is not reported on my service.

But in some aspects opportunity is right. Example: - PHP scripts on all accounts on the server return error 500 for 11+ hours without a fix - I wouldn't call it "professional-grade web hosting"; - if not above, then all accounts return "account queued" page for several hours from time to time - I wouldn't call it "professional-grade web hosting"; - domains/subdomains can not be added for days - I wouldn't call it "professional-grade web hosting"; - whatever unexpected will happend it may take from hours to days until admin with enough privileges will take care off; - etc. "What is written on the front of the box is not found inside of the box. Somebody had a vision that somehow seems to be different from what the reality is of today." opportunity's words quoted above are true. I know much worse webhosts than HelioHost, it's not that bad, even some of the paid hosts are worse. HelioHost can be enough to do some tests if such script/configuration/whatever will work or not or even for some unimportant websites that are not critical to be online all the time... But no-one will convince me that this is a "professional-grade web hosting", such statement is simply untrue. -------------------------- I know that this is not possible, 99+% of the people on the world will tell me that I should go and have my head examined, but I would really like to see "on the front of the box" truth, only truth and the whole truth about ANY product or service.

Hi Since ~06:08 UTC (~22:08 PST) all PHP scripts on Stevie's accounts return error 500. Static HTML pages are fine. That was already the case few times in the past. / Piotr

<general statement, NOT specifically about HelioHost and this situation> The most sad for me part is that that almost no-where in this world (no matter if it's webhost or any other product or service) the front page says the truth and the whole truth about what the product or service is. There is almost always at least some bottom line, small print on last page, or sometimes the front page contain simply lies or idealized vision and the truth about product is hidden. Some people call it marketing... and it exists even for a free products. Well... Few years back I was very involved/engaged in fighting with such so called "marketing" (read: lies on front page), unfortunatelly this is a fight with windmills... Maybe if we (humanity, at least some of us) will be enough determinated something will gonna change in 50, 100, 200 years, but not in a short term, unfortunatelly... </general statement, NOT specifically about HelioHost and this situation>

Yes, using .htaccess will make it available for all scripts. I've suggested to do this in PHP for being able to also GET the DEFAULT settings that randomly change on Stevie as I like to investigate what is incorrectly before setting it up in the way it will work for myself. @ Sherder If you're interesting in what may be the reason of this issue and further details about it, you may want to read this post: http://www.helionet.org/index/topic/10891-weird-behaviour-of-clock-on-stevie/page__view__findpost__p__74868 .

I've got some additional info that possibly may give someone an idea of what the reason of this small issue may be. Do you remember this topic about server time going back and forward 2 hours? http://www.helionet....time-of-server/ Well... I was right in my assumptions that these two things may be related. Before I was checking only the time provided in HTTP headers. And this time - at the moment (2011-12-05) - is 24 seconds behind most of the time, but sometimes it's correct. But now I have started to check also the time displayed with the date/time functions inside of the PHP scripts. And what?... This time seems to be always correct (seems to be, as I still base only on manual tests done more than 100 times). And now the relation between time and default time zone... Every time when the time in HTTP headers is 24 seconds behind - the default time zone used in all date/time functions in PHP scripts is set to "America/Los_Angeles" (GMT-8 / PST). The TZ environment variable is empty. Every time when the time in HTTP headers is correct - the TZ environment variable is set to "America/Chicago" (GMT-6 / CST). There is one more important thing in it. Not only the time in "Date" HTTP header jumps back and forward 24 seconds. The time in "Last-Modified" HTTP header (If exists, ie. for static content like *.html URLs) jumps these 24 seconds, too. So now my assumption is that the clock itself is not desynchronised and don't really jump back and forward. It is synchronised correctly. So you were looking most probably in the wrong place (ntp and rdate). Something randomly adjust the -24 seconds offset to the time provided in HTTP headers while keeping TZ environment variable empty; OR instead keeps the time in HTTP headers without any offset but sets the TZ environment variable to "America/Chicago" (which overrides default time zone used in PHP scripts unless the script itself will set different TZ variable). .

Midnight for me in Poland. ; ) Anyway... additional note for you: Stevie's (the server your website is on) clock "jumps" back and forward 24 seconds (it's either correct or 24 seconds behind). Admins don't know why is that so far. Default timezone being switched may be related to the same problem. I think I'll test it when I'll find a time and inclination.

There is no such time zone like "XYZ". ; ) Sorry, that was just an example on my side. You may want to put "TZ=EST" or "TZ=America/New_York" etc. Place putenv("TZ=your_desired_timezone"); at the very beginning of your script and then the time for you should be displayed correctly (unless in some other place of your script you will change timezone again). All valid time zones you can find here: http://php.net/manual/en/timezones.php But I'm curious... if YOU (your script) don't change timezone randomly... why is this changing by itself?... I may test it later.

Note that CloudFlare will work only for a static content. It's a kind of proxy that in case of original server being down may show the copy of your page made before. You may want to carefully set the cache dispositions, expire times etc. sent with your pages. It will not work at all for dynamic content, the CloudFlare's proxy have to access original server every time anyway, so if original server with dynamic content is down, CloudFlare won't show your page but just an error page.

For me it jumps 2 hours back and forward on your example. If I refresh it many times then usually it shows time in GMT-0800 (PST), but sometimes in GMT-0600 (CST), while byron's page display time in GMT-0500 (EST). Are you sure your script does not change the time zone used for some reason? putenv("TZ=XYZ"); Do you have the same results if you'll echo just the time with having nothing more in the script? Eventually add to the script the following to confirm if the timezone is not switched: echo getenv("TZ");

...how can it be... Cache. You didn't really load the sign-up page from the server, but just the copy made before on your own computer. Next time try to simply clear the cache (temporary internet files) of your browser. Admins still didn't change the HTTP headers that are sent with the sign-up pages so it can be cached even for 1 month on your own computer and may be a problem for many people, just like for you. I wrote about it here already: http://www.helionet.org/index/topic/10853-trying-to-signup/page__p__73381#entry73381

It looks that ns2.heliohost.org has lost some DNS records: - for main "heliohost.org" domain name (that's why my monitor display it as orange); - for "johnny.heliohost.org" subdomain"; - for "ns1.heliohost.org" subdomain; - possibly more. It's fine for "www.heliohost.org", "stevie.heliohost.org", "helionet.org", "www.helionet.org", "wiki.helionet.org" etc. By the way... It's little annoying that IPB automatically edit the topic titles. Personally I would prefer "NS2 has lost some DNS records" instead of "Ns2 Has Lost Some Dns Records". ------------------- ~08:40 UTC seems to be fixed.

The IP you use is most likely incorrect. You have to use the IP where your domain name is located, not where the nameserver is located. To get the right one: - you can either find it inside of cPanel, in the left column in the row labeled "Shared IP Address"; - or using some DIG - in example in here: http://heliohost.grd.net.pl/dns-checker/ - find the IP in the DNS records existing on HelioHost nameservers; - or you can just ping the *.heliohost.org subdomain assigned with your account (if you have one). For websites on Johnny this will be usually 64.62.211.131, for websites on Stevie this will be usually 216.218.192.170. But NOT always! Various accounts/domains may be pointed to various IPs of these two servers, especially Stevie has a lot of them.

No. It's again -24s or correct in the ~50/~50 proportions (based on manual multiple checks, but one could make a bot and log exact results if needed). Just saying, it's not any big problem. Weird one, though.

@ cl58 I think you misunderstand or don't understand DmC. He wants to: - at domain registrar set the authoritative nameservers as: ns1.heliohost.org, (ns2.heliohost.org)?, nsX.some_dns_service.com, (nsY.some_other_dns_service.com)? - on ALL authoritative nameservers, including heliohost nameservers and that other DNS service nameservers set identical records: A, CNAME, MX, etc. and NS, of course, too. @ DmC I don't know if (and how) you can add NS records on HelioHost nameservers, I'll let someone else answer, but even if you won't be able to add such NS records in here it still may work for you. This won't be good if records won't be consistent on root nameservers and all the authoritative nameservers used by you, but it still should work. Alternatively you can use the other one as primary and HelioHost nameservers as secondaries, so the primary would have the right records, consistent with these on root nameservers (set at registrar).

Better now. Still weird, though. Yesterday time on Stevie was either correct or 24 seconds behind randomly somewhere around 50:50 or maybe 60:40 / 40:60 - I didn't really count it, but have checked manually tens of times (maybe even ~100). Today when I've tried the same tens of times (up to ~100, maybe) - time reported by Stevie was usually 24 seconds behind, however couple of times it was correct. So usually it's 24 seconds behind, but sometimes, very rarely it "jumps" and is correct for a moment. As I didn't ever (before yesterday) check it so many times, it's possible that this was always the case for Stevie. Or not, I don't know, I have no any data about it from before yesterday, I can only say that it's possible.

This issue is not in any way critical. This issue does not affect me, by myself in any way. But I found it weird... If you will try to access Stevie multiple times and look at the current time reported in HTTP headers, you may spot that the time on this server "jumps" back and forward every couple of seconds (or maybe even every second) and the difference is 24 seconds. The time is either correct or 24 seconds behind (and nothing between). Previously I didn't spot it ever, every time I was checking it (on my "Server Time Info" page) the time on Stevie was 24 seconds behind. But today I have spot it correct - I though: "Oh! Someone finally have set it up. : ) ". But couple of minutes later - 24 seconds behind, again. "What?...". So I have started to manually check it every 1, 2 or 3 seconds and... surprise. There may be something wrong with ntpd on it. But again: this is not in any way critical issue and does not affect me at all. I've just spot it and for a case no-one else did - I am posting about it.