For troubleshooting and diagnostic purposes, it is possible to use stackato ssh to access a container that has recently failed or did not start correctly. Containers are kept for one hour before being reclaimed. See the Command Reference for details on the stackato ssh command.
Most Stackato users will not have administrative access to the server. If you need to troubleshoot an application deployment or runtime failure, you can use the stackato client to view the stderr and stdout log files. For example, if an application called myapp did not deploy correctly, run the command:
$ stackato logs myapp --all
This will generally show all errors encountered during deployment.
If you need to view another log file (e.g. one specific to your application), use the files command to explore the remote filesystem and return the contents of the files:
$ stackato files myapp logs
stderr.log 44B
stdout.log 101B
myapp-err.log 189B
$ stackato files myapp logs/myapp-err.log
If that command should fail, try using the run command in combination with ls or cat:
$ stackato run myapp cat ../logs/myapp-err.log
If you need to troubleshoot or monitor Stackato logs with a third party, they can be found in the ~/stackato/logs/* directory on the Stackato server.
These logs are under daily log rotation with the use of logrotate. Up to three days worth of compressed logs are kept before deletion of the oldest archive.
To modify the log rotation, edit the /etc/logrotate.d/stackato file as needed. To disable Stackato log rotation, delete the file or move it to another folder.
There may be cases where resolving an issue requires a complete view of the system metrics. This functionality is provided by the stackato admin report command. It generates a single file (by default named <target>-report.tgz) that can be provided to the Stackato support team for analysis:
$ stackato admin report
The file is several megabytes in size and will take a few seconds to generate. Send it, along with a detailed description of your problem, to ActiveState at:
When pushing an app, the Stackato Client reports OK but app isn't running
The final output from pushing an app should look like:
Staging Application: OK Starting Application: OKIf the app is being pushed to multiple instances, the client waits until at least one instance is running, and exits at that point (it does not wait until all instances are active). If afterwards you run stackato apps and find the Health status at 0%, it is because the app crashed after starting successfully, not because the Stackato client reported incorrectly.
DNS queries returning "connection refused"
This error is reported when the Stackato server does not have an IP Address. To investigate and resolve, try the following:
Verify the ARP tables on the hypervisor host, and on the Stackato server through its tty console:
$ arp -nCheck that the DHCP client is running:
$ pgrep dhclient $ grep dhclient /var/log/syslogConnect to the DHCP server and verify that it is receiving client requests from the Stackato server.
If your network is statically configured, assign an IP address on the Stackato server by editing the interfaces file:
/etc/network/interfaces