Troubleshoot Errors on Bitnami Cloud Hosting Servers

Troubleshoot server operations

Check server status

Check the status of your servers in the Bitnami Cloud Hosting console, in the “Manage Server” section. The “Properties” tab shows the state of each server together with the estimated progress of the operation.

Server status

Click the “more info” link to learn more about the current state of the server. This shows CPU usage and cloud-specific metrics like disk, system and instance status.

Server status

The “Last Operation” tab shows details of the last server operation.

Server status

The “Last 10 Operations” section shows a quick summary of previous operations:

Server status

Troubleshoot an “Impaired” server

System and instance status may be Ok or Impaired. The status Impaired indicates a problem with the system or instance, as described in Amazon Web Services (AWS) documentation:

  • “System status checks monitor the AWS systems required to use your instance to ensure they are working properly. These checks detect problems with your instance that require AWS involvement to repair. When a system status check fails, you can choose to wait for AWS to fix the issue or you can resolve it yourself (for example, by stopping and restarting or terminating and replacing an instance)."

    | To resolve this, try a complete reboot of the server, as described later in this guide.

  • “Instance status checks monitor the software and network configuration of your individual instance. These checks detect problems that require your involvement to repair. When an instance status check fails, typically you will need to address the problem yourself (for example by rebooting the instance or by making modifications in your operating system). Examples of problems that may cause instance status checks to fail include: Failed system status checks, Misconfigured networking or startup configuration, Exhausted memory …"

    | To resolve this, check the system log file, which is at /var/log/syslog (Ubuntu) or /var/log/messages (Amazon AMI Linux, Red Hat).

Read the AWS documentation for more information.

Resolve “Unexpected Error” messages

There are several possible reasons for a server operation such as “Server Build”, “Server Start”, “Server Resize” and others to finish with an “Unexpected Error” message or with a server being in the “Pending” state for long period of time. Use the list below to identify what might have gone wrong.

Server remains in “Pending” state

For every server operation executed, Bitnami Cloud Hosting ensures that the server is in the correct, ready-to-run state. This means that the Bitnami Cloud Hosting dashboard has to wait for the server to be in that specific state to continue the process of setting up applications on it. Sometimes, the AWS EC2 API returns a response that the server is “Pending” when in fact the server is available. In these cases, the server operation may take more time than usual. This part of the process depends on the responsiveness of AWS.

Static IP address was assigned to your instance

Once the “change IP address” operation is executed, Bitnami Cloud Hosting waits for the server to respond from new IP address. This sometimes takes additional time and is dependent on the responsiveness of AWS.

Your AWS credentials are not valid

This error could occur if:

  • You use special AWS IAM user credentials and that IAM user account does not have the permissions required by Bitnami Cloud Hosting. As a result, Bitnami will not be able to execute operations on your behalf. To resolve this, use a different IAM account or give the account elevated permissions.

  • You changed or reset your AWS Access Key ID and Secret Access Key. To resolve this, update these credentials in Bitnami Cloud Hosting.

Required ports are not open

Please make sure that ports 22 and 80 are open in your AWS security group settings. If you need to keep those ports closed, you must at least open them for the IP address Bitnami uses these ports to check if the server is available and to collect monitoring data.

Troubleshoot server performance

Check available resources and running processes

There are several possible reasons why your server might be under-performing. Use the list below to identify what could be affecting it.

  • Check the server type and ensure that it has the necessary CPU and RAM resources to meet your application requirements and user load.

  • Check if your application is using a cache. Consider enabling a cache if one is not already present. For applications like WordPress, caching plugins like W3 Total Cache can produce a significant improvement in performance.

  • Check if there are any cron jobs running on the server and consuming resources.

  • Review the server dashboard or monitoring page and check the list of processes consuming CPU and memory. Alternatively, log in to the machine console via SSH and execute the following command to see a list of running processes:

      $ ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS
      $ ps -e -o pcpu,nice,state,cputime,args --sort -pcpu | head -10
  • Check available memory, as low memory affects application and/or database performance and connectivity. Use the following command to see the available and used memory:

      $ free -m
  • In case of problems with the disk size, check the free disk space and which directories have a large number of files:

      $ df -ih
      $ df -h
      $ cd /opt/bitnami
      $ sudo find . -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
      $ du -h -d 1
  • Try performing a complete reboot of the server.

  • Check if your server is being accessed by suspicious IP addresses and block them if so. Refer to the FAQ for detailed instructions.

Reboot the server

If you are experiencing performance problems, sometimes it is useful to perform a complete reboot.

Server reboot

  • A hard reboot operation will first stop your instance and then start it again. This will occur if the option “Perform complete reboot” is selected.

  • A soft reboot operation will just reboot the operating system. This will occur if the option “Perform complete reboot” is not selected.

If the instance is located on an AWS degraded host or if a Micro instance has performance issues, then a hard reboot operation may fix it.

NOTE: The instance’s IP address will change if a static IP address is not assigned and you choose a “complete reboot”.

Block suspicious IP addresses

To obtain a list of IP addresses sending requests to your server, run the command below:

$ tail -n 10000 /opt/bitnami/apache2/logs/access_log | awk '{print $1}'| sort| uniq -c| sort -nr| head -n 10

Once the list of addresses has been generated, check their activity with the following command. Substitute the IP-ADDRESS placeholder with each of the IP addresses from the list.

$ cat access_log | grep IP-ADDRESS

If an IP address is not a known internal or external IP address and its behaviour is suspicious (for example, accessing only one page or attempting to log in multiple times), it could be a bot.

Block a suspicious IP address using the iptables command. Substitute the IP-ADDRESS placeholder with the IP address you wish to block:

$ sudo su
$ iptables -A INPUT -s IP-ADDRESS -j DROP

NOTE: Use this with caution. If you don’t specify an IP address, you will block yourself.

To delete a rule, execute these commands. Substitute the IP-ADDRESS placeholder with the IP address you wish to allow:

$ sudo su
$ iptables -D INPUT -s IP-ADDRESS -j DROP

To have a rule active when the machine reboots, define the rule and then follow these steps:

  • Execute the following commands:

      $ sudo su
      $ iptables-save > /opt/bitnami/iptables-rules
      $ crontab -e
  • Edit the crontab file and include this line at the end of the file:

      @reboot /sbin/iptables-restore < /opt/bitnami/iptables-rules
  • Save the file and exit. This way, on every boot, the system will load the iptables rules and apply them.

Last modification March 6, 2020