Django, Gunicorn, Systemd Errors

gunicorn.errors.HaltServer: <HaltServer ‘Worker failed to boot.’ 3>

Derrick Gee
2 min readDec 1, 2020

Getting this error while trying to deploy a Django app? Check the logs with this command:

journalctl --unit=gunicorn | tail -n 100

With this command, you can see gunicorn trying to startup your Django app more clearly compared to sudo service gunicorn status .

If your systemd socket/service settings file ( /etc/systemd/system/* ) contains the setting EnvironmentFile , make sure to check the format of your env file. It cannot be the bash script format like this:

export MY_KEY=123
export MY_OTHER_KEY=aaa

Correct format:

MY_KEY=123
MY_OTHER_KEY=aaauld

If your gunicorn is active and running from sudo service gunicorn status , but your website still doesn’t show up. Try the following:

Make sure your ALLOWED_HOSTS in your Django project’s settings.py has the correct domain names:

# settings.py
ALLOWED_HOSTS = ["example.com", "www.example.com"]

If you are hosting with a domain of something like .dev or .page , those domains require HTTPS to even let you go to the IP address. It becomes a little circular if you are wanting to test your site on a port, as you need to enable HTTPS without testing to see if the site’s homepage works. But the homepage should be working if it works locally, and if gunicorn is throwing an access log of this sort when trying to ping your server’s IP:

"GET / HTTP/1.1" 301 0
code 400, message Bad HTTP/0.9 request type
You're accessing the development server over HTTPS, but it only supports HTTP.

All you need to do is use certbot to enable HTTPS before testing your homepage, which is pretty straightforward from their instructions. After running sudo certbot --your_webserver , or whatever the instructions gave for your specific specs. Your domain should be ready to test if no errors came up.

If any errors came up during certbot , consider checking your DNS records and domain provider settings.

--

--