Debug containers

Logging

Triton supports Docker log drivers like syslog, Graylog, and Fluentd. If you specify no custom log drivers, then Docker containers on Triton log as you'd expect. Check the logs with:

triton-docker logs <container name or UUID>

If you have an alternative approach to logging, such as running syslog in your container, you might rather just use an infrastructure container, which will make it easy to run all the services you'd expect of a unix host.

If your logging solution depends on writing logs to a volume mapped in from the host, you'll have to ask yourself "where's the host?" Read our discussion on volumes.

Debug containers without logs

Sometimes your container image may have an error that prevents it from starting as you expect. If the error happens early enough—before the container's main process starts—the error won't appear in the Docker logs. There's a separate log that includes all the details of what SmartOS did to start your container (including any errors if it failed) in /var/log/sdc-dockerinit.log.

You can inspect that log in a running container, but if the startup failed, you can use triton-docker cp to get it from the stopped container:

triton-docker cp <container name or UUID>:/var/log/sdc-dockerinit.log <local file>

Often times you'll discover an error in the image's permissions or that the RUN or ENTRYPOINT executable is missing. If the problem still isn't clear, contact support.