wolstech

No it should not affect the ability to log into Plesk. If you cannot sign in through https://heliohost.org/login/ , my next suggestion would be to try resetting the password.

Domain changed. It can take 2 hours or more before it works.

You're suspended because WordPress got hacked and your account is full of malware. This is extremely common for Wordpress and is a major reason we recommend avoiding it. Because the account is full of malware, you'll need to reset your account (which deletes your data) and start over. Are you ready to reset your account?

Load is coming from systemd, which is caused by either excessive cron job runs or FTP connections being used heavily or left open for long periods. Another user who had excess load from systemd solved it by reducing the frequency of their cron jobs.

Domain added. Please be sure to configure DNS for the domain. The domain can take up to 2 hours to work.

Glad to see its working for you now Please let us know if you need anything else.

Below is the zone file for your domain. Note that we do not allow external DNS for .helioho.st domains. If you were looking for this information so you could switch DNS providers, you'll need to get a domain that does not end in .helioho.st or .heliohost.us to do that. tanzilskill.helioho.st. IN A 64.62.151.106 tanzilskill.helioho.st. IN AAAA 2001:470:1:1ee::2009 ipv6 IN AAAA 2001:470:1:1ee::2009 tanzilskill.helioho.st. IN MX 0 tanzilskill.helioho.st. mail IN CNAME tanzilskill.helioho.st. www IN CNAME tanzilskill.helioho.st. ftp IN CNAME tanzilskill.helioho.st. webmail IN A 64.62.151.106 webmail IN AAAA 2001:470:1:1ee::2009 tanzilskill.helioho.st. 14400 IN TXT "v=spf1 ip4:64.62.151.106 ip6:2001:470:1:1ee::2009 ~all" _dmarc 14400 IN TXT "v=DMARC1; p=quarantine" _domainkey.tanzilskill.helioho.st. 14400 IN TXT "o=-" default._domainkey.tanzilskill.helioho.st. 14400 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApPOa/DOn4YrLa3enxk53aqS92AewBWw1rEKemQhEy0uWcmgTO6acu58zQ0lLWn7UBd/NcdKU48Na+/QZPMjlu4SpnpPb0VPHJp5jbzMmodC7h5EqXotpemlySytYpf0/ihOD08HHSMHaTInxq1XwN8EEMn6yYR/sLGjB2dRTcUSlrLNbgZ+UXgKuWHywo3Kfj" "rGQxTRtHRVZjty1qEBSF/fkmofov6a46DM6JzFYyEM8vnFLp+Ei/5y7FZaZZuz0417G5Z4QLrwekDM9WX32AsEar/taIWiYKTiBXMMMRfqtOEWT823SQZ2ITozakgLugOqQIAlad6hGgN4v5ItFHQIDAQAB;" )

Fixed. So this is a weird one. Composer broke because the composer.json that was loaded in Plesk was deleted (which is why the app folder was set to something in .trash). My guess is git moved the old versions to the trash when it updated them, breaking Composer. I had to manually run a command as root to re-register httpdocs as the app folder for your composer, then switch it back for you in the UI. The old broken folders are still going to show as options as there is actually no way to remove them from the system short of manually editing composer's database. It now shows 2 up to date dependencies and 1 not installed. If this is being caused by git deleting the composer.json, the unorthodox solution of committing the vendor folder to the git may very well be the best solution...

Do you mean you want to see what entries are in the DNS zone for your domain? Or do you want us to add specific records (and if so, what do you want added?)

Plesk calls the document root of the main domain httpdocs, but it does the same thing as the www folder on other services. We typically avoid renaming this because it can cause issues with the account. The name of the default docroot tends to vary depending on the control panel and server configurations. Other control panels call it things like www, htdocs, or public_html.

High server load due to excessive CPU...leaving your FTP connection open will indeed cause that. Please be sure to disconnect when not using it to help keep the load down. Unsuspended. It may take a few minutes to work again.

Looks like you installed it from Softaculous. You can uninstall it from this page: https://tommy.heliohost.org/modules/softaculous/index.php?act=installations Click the red trashcan icon next to the installation and follow the prompts. After that, if it doesn't remove them automatically, you can delete the files and drop the database.

They’re the same thing.

Load is coming from systemd. Krydos will need to research what is causing this as it's not normal. We didn't have a single CPU suspension for 4 months, then suddenly had several yesterday all for load from systemd. One suggestion mentioned in a staff channel was that it might be caused by SFTP connections being left open for long periods. Are you using SFTP heavily? If so, does your client disconnect the session after transferring files?

Whatever was running was using way too much CPU. CPU limit is 10000 units/day, RAM is 200GB/day. Are you ready to fix the issue? If so, let us know and we'll unsuspend you.