Jump to content

wolstech

Chief Risk Officer
  • Posts

    17,035
  • Joined

  • Last visited

  • Days Won

    617

Everything posted by wolstech

  1. Apache seems to be yes...http://heliohost.grd.net.pl/monitor/
  2. Can you try a different internet connection (your ISP may have cached something that they shouldn't have)?
  3. The domain ayegbajosh.com has been cleaned up.
  4. It just means the server couldn't recreate your mysql databases during restore. The folder given /home/mickeyme/cpmove_failed_mysql_dbs.156744930 should contain the .sql files with the database contents. If you want to restore the databases, you can download the files, create a database in cpanel, then import the .sql file from the backup page. If you're not concerned about the contents, yes we can delete your account and send you an invite for a new one instead if you wish.
  5. The account alanbald has been unarchived and should start working in the next few minutes. Domains for both of these accounts may take up to 2 hours to become functional.
  6. The account mickeyme has been unarchived, however the mysql restoration failed due to a server error. You may need to use the files in the folder shown in the below error to restore your databases: [ 3585][RESTORE:1 ][A:mickeyme ]: Warning (“MysqlBase::_create_db_and_import_as_newuser_from_mysql_dbfile”, line 540): Failed to remove empty DB “mickeyme_mage224”: (XID tqrme9) The system received an error from the “MySQL” database “mysql”: 2006 (MySQL server has gone away) [ 3585][RESTORE:1 ][A:mickeyme ]: Warning (“DBBase::save_databases_in_homedir”, line 138): The system has saved the database archive data in the directory “/home/mickeyme/cpmove_failed_mysql_dbs.1567449308”. You may use this directory’s contents to restore your data manually. [ 3585][RESTORE:1 ][A:mickeyme ]: Warning (“Mysql::_restore_databases_and_map_them_to_cpuser”, line 178): The system failed to reinstall the MySQL database “mickeyme_mage224” as “mickeyme_mage224” because of an error: The MySQL server reported an error (MySQL server has gone away) in response to this request: /*!40101 SET character_set_client = @saved_cs_client */ at /usr/local/cpanel/Whostmgr/Transfers/SystemsBase/MysqlBase.pm line 294, <$_[...]> line 7580. [ 3585][RESTORE:1 ][A:mickeyme ]: Skipped item (“AccountRestoration::_run_restore_system_module”, line 437): The “Mysql” restore module failed because of an error: (XID 2fx2yw) The system received an error from the “MySQL” database “mysql”: 2006 (MySQL server has gone away) [ 3585][RESTORE:1 ][A:mickeyme ]: at /usr/local/cpanel/Cpanel/DBI.pm line 200. [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::DBI::_create_exception(Cpanel::DBI::Mysql::db=HASH(0x38be830), "DBD::mysql::db selectrow_array failed: MySQL server has gone "..., undef) called at /usr/local/cpanel/Cpanel/DBI.pm line 188 [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::DBI::_error_handler("DBD::mysql::db selectrow_array failed: MySQL server has gone "..., Cpanel::DBI::Mysql::db=HASH(0x38be830), undef) called at /usr/local/cpanel/Cpanel/MysqlUtils/MyCnf/Basic.pm line 242 [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::MysqlUtils::MyCnf::Basic::get_server_version(Cpanel::DBI::Mysql::db=HASH(0x38be830)) called at /usr/local/cpanel/Whostmgr/Transfers/Systems/Mysql.pm line 852 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers::Systems::Mysql::_restore_dbowner_password_and_privs(Whostmgr::Transfers::Systems::Mysql=HASH(0x665f840)) called at /usr/local/cpanel/Whostmgr/Transfers/Systems/Mysql.pm line 185 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers:…hostmgr::Transfers::Session=HASH(0x37a61c8), 0, "johnnyheliohosresto201909021709366p7") called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 183 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers::Session::Processor::__ANON__() called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 67 [ 3585][RESTORE:1 ][A:mickeyme ]: eval {...} called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 67 [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::ForkAsync::do_in_child(CODE(0x253c760)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 185 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers::Session::Processor::start(Whostmgr::Transfers::Session::Processor=HASH(0x3e3f6c0)) called at bin/restorepkg.pl line 319 [ 3585][RESTORE:1 ][A:mickeyme ]: bin::restorepkg::__ANON__() called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Try/Tiny.pm line 99 [ 3585][RESTORE:1 ][A:mickeyme ]: eval {...} called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Try/Tiny.pm line 90 [ 3585][RESTORE:1 ][A:mickeyme ]: Try::Tiny::try(CODE(0x37a63f0), Try::Tiny::Catch=REF(0x37a1998)) called at bin/restorepkg.pl line 324 [ 3585][RESTORE:1 ][A:mickeyme ]: bin::restorepkg::script("bin::restorepkg", "mickeyme") called at bin/restorepkg.pl line 54 Now unarchiving alanbald...
  7. Piotr GRD described exactly the issue we've been seeing for the past week until a few days ago. It's better for busted NSes to be down entirely, because if it times out, the requesting device just asks the next one in the list. If it gets an answer, it just assumes that the information received is correct. NS1 was alive after Tommy came up, but until recently, had not been informed of most of the domains we have.
  8. Johnny is actually up (at least enough that SSH is still connected...), but these taking forever due to Johnny being extremely overloaded. Mickeyme has been hung restoring a 400+MB homedir for an hour and I haven't even started the second one.
  9. Wow, this somehow got missed and was bumped over a year later Unarchiving...
  10. Well that one's new. NS1 is the one that's been giving us issues. The domain dl5ark.heliohost.org has been synced onto NS2. > dl5ark.heliohost.org Server: ns2.heliohost.org Address: 64.62.211.133 Name: dl5ark.heliohost.org Address: 64.62.211.134
  11. Donation verified, you donated on September 3, 2018. Invite sent. Just make sure you don't reuse your old main domain. That'll cause the creation to fail. If you need domains cleaned up, let us know and we will get it taken care of.
  12. That was probably caused by Krydos fixing NS1. I had a few records get changed randomly too (though mine were not MX). I would just change them again. If they change back a second time, let us know and I'll get Krydos to look at it for you.
  13. All of our servers have Ruby. It's Rails that you're probably thinking of. We no longer support Rails. I don't know whether Jekyll would run on Ricky, but badrihippo's idea of designing and generating the site on your PC and uploading the resulting files would work just fine.
  14. It's partly because we have no physical presence. We have no office or employees. There's nobody to cash it. Our entire physical existence is a rented server rack and some paperwork (seriously, that's it!) The issue with mailed donations is that they require effort and resources to cash (have to have a person open them, take the check to the bank, etc.), have high fees if they bounce ($30+ per check, and too many might cause your bank to close your account), and are generally a pain to deal with for other reasons (e.g. someone filled it out wrong, etc.). As a result, we accept electronic donations only, and have no plans to accept checks, cash, or other physical media of any type. If there's a specific type of electronic donation you think would be worthwhile for us to offer, we're definitely interested in hearing those ideas
  15. That account was archived when the server crashed. Do you want me to restore it to Ricky or Johnny for you, or would you rather me email it to you? Since it was archived before the crash, it can just get restored like any archived account, as opposed to you having to download it and manually set everything up again.
  16. The domain shop-n-america.us has been cleaned up.
  17. The domain nelsonaraujo.com.br has been cleaned up. Also, since Krydos hasn't responded in over 2 weeks to this, invite sent so you can at least get back to business. Krydos can always just suspend you if we can't find the donation.
  18. I just cleaned it up again, then parked the domain for you. It should start working shortly. Not sure why it didn't work the first time...
  19. Yep. That's exactly what I was going to do, and everything in there is looking good Your DNS issues have cleared up and are normal. If mail to the zaldivar.mx domain is having trouble delivering at this point, it's due to Ricky being overloaded. The infantex domain is configured for google as expected and you said that is working properly, so that's good to go as well.
  20. The receiving issues probably improved overnight. It turns out that NS1 was broken and missing tons of zones. I’d be willing to bet the receiving issues were because remote servers couldn’t find your domain due to the broken NS. Can you verify that zaldivar.mx resolves correctly when ns1.heliohost.org is queried as the name server (I’m on mobile so can’t test easily)? The intermittent nature of the issue was because when one NS is broken, the result is different depending on which server is asked for information. If one mail server asked ns1, it would fail, meanwhile if it asked ns2 the next time, it’d work... As for email sent from Ricky taking a half hour to arrive, yeah, that’s load. I had one take 8 hours. The mail server is just really backed up on sending messages.
  21. NS1 had a corrupt named.conf which explains why it wouldn't sync...Krydos fixed that and resynchronized it. Is your domain on NS1 now? @sohamb03: I don't remember, which is why I didn't list it. I only know a second one exists because I remember helping someone and saying "oh, it's like a .br". The .br is the original tld that was like this.
  22. The .br TLD is is one of only two TLDs in the entire world that require this, and as a result they're incompatible with most hosting companies (including us). Why they require this nonstandard configuration process is beyond me. Normal TLDs expect the records first, then the name server be configured second. NS1 is still broken. It's missing a ton of zones at the moment for some reason. I'll ask Krydos about this...
  23. The specified domains cannot be cleaned up because they don't exist. EDIT: That'd be why...
×
×
  • Create New...