Troubleshooting
Lost/unknown job ID
The first step in any investigation is knowing a job ID. If you started your job with apolo run
, the job's ID was printed in the output.
However, if you can't find the initial terminal output, you can use one of these commands to find a specific job:
Note: apolo ps
is a shortcut for apolo job ls
apolo ps
prints only running jobs.
apolo ps -a
prints all jobs.
apolo ps -s failed
prints all jobs with the Failed status.
Image build failed
When you run apolo-flow build IMAGE_NAME
, apolo-flow uploads the build context to the platform and creates a platform job that uses Kaniko to build a docker image and push it to the platform registry.
If building fails, you can check the job's status and logs to get more information.
Getting a job's status
To check a job's status, run:
The Status transitions section in the output can help you learn at which step the job failed.
Getting builder logs
To check builder logs, run:
apolo run / apolo-flow run failed
There are a few main reasons your job may fail. Here are some of the most common:
Incorrect image name
This can happen if you have a typo in the image name or if the specified image was not built before running a job. List of all images can be accessed by running apolo image ls
. You can also list tags for a particular image via apolo image tags <IMAGE_URI>
.
Incorrect volume mounted
You might have an invalid volume mounted to the job. For example, you've mounted a volume to the /my-project
folder, but your code expects /my_project
. You can double-check it in the logs.
Cluster scale up failed
If you see a Cluster Scale Up Failed error in the status, it usually means you’ve requested resources that are not available in the cluster at the moment. For example, all GPUs are busy, so your job can’t be scheduled.
Code issues
You may have an error in your python script that prevents the job from running properly.
Can’t access my job via HTTP
There are a few steps to troubleshooting such issues.
Checking for an open HTTP port
The first point of interest is whether you have an open HTTP port for your job. To check this, you can:
Use the --http_port
parameter.
Checking the listening IP
Next, make sure that your web app listens on 0.0.0.0, not on 127.0.0.1 or localhost
— otherwise it won't be able to accept incoming requests from the outside of the container.
Disabling HTTP authentication
And finally, if you can access your job via browser, but curl
and similar tools don’t work, most likely you didn’t disable HTTP authentication. The Apolo platform puts an HTTP authentication layer in front of your app by default for security reasons.
You can disable this behavior manually when running jobs:
Use the --no-http-auth
parameter.
Troubleshooting a running job
Just like with Docker, you can get a shell in a running job to check its state. To do this, run:
Note: In Docker you would typically add the -it
parameters to the command, but they’re not necessary for apolo exec
.
Navigating job statuses
A job might have one of the following statuses:
Each of these statuses have additional sub-statuses that can help you monitor the job and trace errors on an more granular level:
Last updated