Workaround for KAMAL_DESTINATION not available in Docker container env vars

[tom-spalding]

Hey friends, love Kamal! using it for everything now.

I noticed that KAMAL_DESTINATION isn't available as an env var in my docker containers that are deployed by specifying a destination. ie kamal deploy -d staging or kamal deploy -d production. I saw that #1019 exists, but here's how I tested.

> docker ps
CONTAINER ID   IMAGE
5af5aa2e09de    ...

> docker exec 5af5aa2e09de env
PATH=/usr/local/bundle/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=123.123.123.170-b976c50b72f9
RAILS_MASTER_KEY=xxxxx
KAMAL_CONTAINER_NAME=app-web-production-ae4beca3a15481a70df97d0d50d0b5010ff6978b
KAMAL_VERSION=ae4beca3a15481a70df97d0d50d0b5010ff6978b
KAMAL_HOST=123.123.123.170
SOLID_QUEUE_IN_PUMA=true
LANG=C.UTF-8
RUBY_VERSION=3.4.1
RUBY_DOWNLOAD_URL=https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.1.tar.xz
RUBY_DOWNLOAD_SHA256=018d59ffb52be3c0a6d847e22d3fd7a2c52d0ddfee249d3517a0c8c6dbfa70af
GEM_HOME=/usr/local/bundle
BUNDLE_SILENCE_ROOT_WARNING=1
BUNDLE_APP_CONFIG=/usr/local/bundle
RAILS_ENV=production
BUNDLE_DEPLOYMENT=1
BUNDLE_PATH=/usr/local/bundle
BUNDLE_WITHOUT=development
HOME=/home/rails

The workaround I'm using is this.

deploy.staging.yml:

env:
  clear:
    KAMAL_DESTINATION: staging

deploy.production.yml:

env:
  clear:
    KAMAL_DESTINATION: production

Its a little redundant but it should be forwards-compatible until available if you're coming here for same question. :)

Made a quick PR to not need this workaround #1634.

[tom-spalding]

Thanks for the help @djmb! #1634 merged.

[edmz]

If you use kamal with cron and execute like the documentation suggests[1]:

servers:
  cron:
    hosts:
      - 192.168.0.1
    cmd:
      bash -c "(env && cat config/crontab) | crontab - && cron -f"

Then cron will fail with something similar to:

"-":20: bad minute

The error will be caused by an environment variable that has no value and makes cron choke. In my case it was KAMAL_DESTINATION. I have other projects that were deployed some weeks ago and they deployed correctly. Only a project that was attempted to be deployed with kamal 2.8.2 (which I think includes the PR #1634) fails to deploy.

If this is the case, we should either filter the ENV vars to not include empty ones or just not make KAMAL_DESTINATION available of it does not have a value.

1. https://kamal-deploy.org/docs/configuration/cron/

[tom-spalding]

Hi @edmz just replying in respect to the crontab error. Does cat -v /etc/crontab help find the bad minute error?

[edmz]

The crontab error is caused KAMAL_DESTINATION being empty.

I narrow this down by dumping what (env && cat config/crontab) generates to a file and feeding different lines that to crontab - until I found the culprit. Like:

(head -n 20 /mnt/cron_debug/combined-20251103T173843.cron && tail -n 7 /mnt/cron_debug/combined-20251103T173843.cron) | crontab -

And it's KAMAL_DESTINATION, in my case, but it can be just any env var that does not have a value:

...
GEM_HOME=/usr/local/bundle
RAILS_ENV=production
KAMAL_DESTINATION=
RUBY_DOWNLOAD_SHA256=658acc455b6bda87ac6cc1380e86552b9c1af87055e7a....
PWD=/rails
...
* * * * * echo OK >> /proc/1/fd/1 2>&1

That is the sample file that chokes cron. Remove the line with KAMAL_DESTINATION= and crontab works.

[tom-spalding]

Makes sense, thanks for the explanation 👍

[edmz]

This is a way to replicate this:

docker run --rm ruby:3.1-slim bash -c 'apt-get update && apt-get install -y cron && printf "PATH=/bin\nEMPTY_VAR=\n* * * * * echo OK >> /proc/1/fd/1 2>&1\n" | crontab - 2>&1 && echo "Success: crontab accepted" || echo "Failed: crontab rejected"'