It’s great to hear that you were able to reproduce the issue.
I have restarted everything multiple times but still no success.
Do you mean the local taskman on my machine or something else?
Did that fix the problem for you?
I’m using mac.
No, I mean taskman service in the installation, on ec2 instance.
Hi,
I’m taking over this thread for Sami.
So as you advised I restarted the EC2 instance. In the AWS console it shows up as running and all status checks show up as OK. But when I enter the public DNS in my browser, I go to a not found page. When I enter the public IP I get a message saying "Server temporarily unavailable. Please contact http://www.backendless.com.
What happened now?
After restarting the public DNS changed to ec2-54-83-176-99.compute-1.amazonaws.com, public IP to 54.83.176.99.
I didn’t mean restarting the ec2 instance itself, only taskman service which is running on that instance.
As I know, ec2 instances change its ip when restarting if “elastic ip” is not used. I guess that it caused you issue with changing.
It’s hard to say what caused your problem now, please send us your log files to support@backendless.com You can find them on your instance, in (installation_dir)/apps/backendless/logs/ folder.
Unfortunately I can’t actually access our instance, as neither the Public DNS or the IP are accessible. Our installation is hosted on AWS. How would I find the logs?
I do understand that the IP and public DNS changed when I restarted the EC2 instance, but shouldn’t the new ones work? Is it generally a problem to restart the EC2 instance? There could be various reasons one may have to do this, it seems.
Can you try to connect to the instance using this instruction: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html ?
About the second question: instance restart should not lead to service failure, we shall investigate this issue. However, if amazon “elastic ip” is not used - your apps endpoint would be changed.
OK, I get this:
Permission denied (publickey).
I did make sure to run chmod 400 /path/my-key-pair.pem as per the instructions, so I know the key file isn’t publicly viewable.
Katia,
We would love to help you with Backendless specific problems, but we really cannot provide support for pure EC2 issues. Once you resolve the problem of entering your instance, you would need to follow the instructions from the documentation to change the address of Backendless Pro:
https://backendless.com/documentation/backendlesspro/st_server_address.htm
Regards,
Mark
Hi Mark,
I do see your point, however, this is the message we see when we try to access our Backendless Pro instance (via the correct new Public DNS or IP):
http://support.backendless.com/public/attachments/da4d2c9af50b68c9edd142efa98c9b59.png</img>
Am I mistaken in thinking this says the issue is Backendless specific?
It’s hard to have confidence in using the platform if we suddenly lose access to our instance, through no fault of ours, and then I’m told by you that it’s an EC2 issue, and by AWS to contact Backendless… We love Backendless, but this is getting really frustrating…
Best,
Katia
Are you saying AWS told you to contact Backendless when you asked “how to get SSH access to an EC2 instance”? That would be crazy…
There may be a number of reasons why this could occur. For example, if you decided to run on a smaller instance with little memory. To understand what happened, you should take a look at the log files.
To see which component is not running, you need to login to your instance (this is the problem you described here and it is something I cannot help you with) and use the utility which is described at:
https://backendless.com/documentation/backendlesspro/st_process_management.htm
Hi Mark,
Thanks for the help! I have successfully ssh-ed into my instance, and I’m trying to update the IP address of the instance. I’m running this command:
sudo ./bnconfig --machine_hostname 34.192.168.206
It seems to be running but it’s taking a very long time. Is this expected? I don’t see any error messages, nothing at all, and the IP address hasn’t been changed.
Thanks!
It finally ended with this error message:
Problem running post-install step. Installation may not complete correctly
Error running /opt/bitnami/ctlscript.sh start play: child process exited abnormally
Here are the contents of playServer.log in case this helps:
Play server process ID is 2866
01:57:01,714 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
01:57:01,715 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
01:57:01,715 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [jar:file:/opt/bitnami/apps/backendless/htdocs/dao-3.6$
01:57:01,715 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
01:57:01,716 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [jar:file:/opt/bitnami/apps/backendless/htdocs/play_2$
01:57:01,716 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [jar:file:/opt/bitnami/apps/backendless/htdocs/dao-3.$
01:57:01,744 |-INFO in ch.qos.logback.core.joran.spi.ConfigurationWatchList@74fe5c40 - URL [jar:file:/opt/bitnami/apps/backendless/htdocs/dao-3.6.0-PRO.jar!/$
01:57:02,602 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
01:57:02,605 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
01:57:02,612 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
01:57:02,624 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder]$
01:57:02,964 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppend$
01:57:02,966 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [ROLLING_FILE]
01:57:03,217 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1072410641 - Will use zip compression
01:57:03,218 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy@1072410641 - Will use the pattern log/application.%d{yyyy-MM-dd}.%i.log for the active file
01:57:03,221 |-INFO in ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP@10e31a9a - The date pattern is ‘yyyy-MM-dd’ from file name pattern 'log/application.$
01:57:03,221 |-INFO in ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP@10e31a9a - Roll-over at midnight.
01:57:03,233 |-INFO in ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP@10e31a9a - Setting initial period to Thu Nov 17 01:57:03 UTC 2016
01:57:03,235 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder]$
01:57:03,239 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[ROLLING_FILE] - Active log file name: log/application.log
01:57:03,239 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[ROLLING_FILE] - File property is set to [log/application.log]
01:57:03,242 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [daojpa] to ERROR
01:57:03,242 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[daojpa]
01:57:03,243 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to INFO
01:57:03,243 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
01:57:03,243 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [ROLLING_FILE] to Logger[ROOT]
01:57:03,243 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
Regarding the error with ctlscript, I will get Bitnami involved with it.
Did you get the play log from?:
<installdir>/apps/backendless/logs/
There should be a lot more logging right after the last line you showed.