title | weight |
---|---|
Troubleshooting |
90 |
Here are some of the most common issues and how to deal with them.
Don't see your issue here? Try our mailing list or contact support at support.appfog.com.
- Crashing app (502/503/404)
- af cli login issues
- af cli installation issues
- Error (JSON 502) on
af update
- Error 402: App packaging failed: 'Failed synchronizing resource pool' on
af update
- App stops by itself.
- Missing logs
- MySQL server has gone away
- WordPress issues
If your app is at less than 100% "Running" status or you're seeing the AppFog error page, it means one or more instances of your app have crashed. You can check this status with the following command:
$ af crashes <appname>
You can get your app's crashlogs with the following:
$ af crashlogs <appname>
(Or if your app has multiple instances:)
$ af crashlogs --all <appname>
If you can log into the web console, but you're running into issues with the af login
command, try this:
$ rm ~/.af_token
$ af login
Some users have been receiving an SSL certificate error when attempting to install the AF CLI tool. Please note that this error has nothing to do with us, but, rather, has to do with an SSL certificate issue at www.rubygems.org which they are aware of and are working to resolve.
Here are a few suggestions for how to work around it:
Try this first:
$ gem install af --source: http://rubygems.org
If the first suggestion does not work, try this:
-
Download the Ruby installer from http://rubyinstaller.org/downloads/ (it is recommended you use Ruby 1.9.3).
-
Then download the version that matches the installer.
-
Once you have unzipped both of those files locally then run the below commands:
$ gem update --system $ gem install af
If the first two suggestions do not work, try this:
$ gem source -r https://rubygems.org $ gem source -a http://rubygems.org $ gem install af
(NOTE: first line will remove the SSL version of ruby gems)
(NOTE: second line of code will install the non-secure version of ruby gems and will give you a warning about it being insecure, so please consider how it may affect the rest of your system prior to implementing this)
The most common reason for this is your app running out of available RAM. When that happens, AppFog kills the app and attempts to re-spawn it. While it's down, you see 404. To fix this, simply add more RAM to your app:
$ af mem <appname> <memory>
Resource pool issues can usually be resolved by bypassing the cache with the --no-resources
flag:
$ af update <appname> --no-resources
Sometimes symbolic links in your code base can cause this error, especially with Node apps. This command will list all of the symbolic links in your directory:
$ find . -type s | xargs -l
If it's a node app, it's likely you have a node_modules/.bin
directory, and that may be the problem. Usually, you can just delete the entire .bin
directory if you aren't using it.
You can also add the following to your .afignore
file:
node_modules/.bin/
An app stopping by itself generally indicates that it has crashed. When your app crashes, AppFog automatically attempts to re-spawn it, but only a limited number of times. If it continues to crash repeatedly, it will remain stopped. You can check your crashes with af crashes
:
$ af crashes <appname>
And you can check the crash logs:
$ af crashlogs <appname>
If your app has more than once instance:
$ af crashlogs <appname> --all
The most common reason for an app to crash is running out of memory. You should find a log message indicating as much in your error logs
$ af files <appname> --all /logs/stderr.log
FATAL -- : Memory limit of 256M exceeded.
FATAL -- : Actual usage was 300M, process terminated.
Apps that have crashed or failed to deploy are wiped (with their logs) after an hour. In the event that af logs
returns no data, you should check af crashes
and af crashlogs
. Failing that, restart and check logs again.
Mysql::Error: MySQL server has gone away
This occurs when an app attempts to use persistent MySQL connections without closing them. AppFog apps should always close database connections and should not use persistent MySQL connections.
Most common WordPress issues on AppFog stem from the fact that AppFog does not yet have a persistent file system. This means that any changes you make to the file system through a web interface, including any admin changes and content uploads, will be lost on the app's next start, stop, restart, deploy, or resource change. Because of this, you should make any changes to the file system on a local development environment and keep media assets and content uploads on an external storage system like Amazon's S3.
Here are some of the issues this can cause:
- White screen
- Reversion back to default WordPress
- Theme/plugin errors