Forums

Have been gone for a while, checking in again and noticed you have found a way to make available eventlet workers for gunicorn. Amazing work, well done! <3

However, there is something which is either a minor, tiny bug - or (less likely?) an implementation detail, that should, in my humble opinion, at least be documented on the help pages.

With

pa website create (...) gunicorn --bind=unix:$DOMAIN_SOCKET (...)

or

pa website create (...) gunicorn --bind="unix:$DOMAIN_SOCKET" (...)

there's only 404 and the webapp is unreachable. Looking at /var/log/***.pythonanywhere.com.error.log shows

[INFO] Listening at: unix:$DOMAIN_SOCKET (1)

So it seems like the environment variable isn't replaced with the correct value. If, however, I am using

pa website create (...) gunicorn --bind=unix:${DOMAIN_SOCKET} (...)

or

pa website create (...) gunicorn --bind="unix:${DOMAIN_SOCKET}" (...)

everything works perfectly fine and /var/log/***.pythonanywhere.com.error.log shows

[INFO] Listening at: unix:/var/sockets/***.pythonanywhere.com/app.sock (1)

I can't come up with a reason why the shell language would differentiate between $DOMAIN_SOCKET and ${DOMAIN_SOCKET}, so I assume there's some magic going on behind the scenes. This behavior was very unexpected to me. Surely, all four command should be equivalent, no?

Just thought I'd let you know. Again, thank you very much for making this possible. :)

Excellent, thanks for confirming it works!

Sorry, something went wrong. Please see edited top post again. Thanks :)

I see! Good catch -- I think we've already stumbled upon this issue, but it looks like we've never updated our help pages. Will make a note about it!

Was curious to see if you've already figured something out about this? Very interesting to see how systemd handles variables differently than POSIX shell:

> Example:
> 
> Environment="ONE=one" 'TWO=two two'
> ExecStart=echo $ONE $TWO ${TWO}
> 
> This will execute /bin/echo with four arguments: "one", "two", "two", and "two two".

From https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#Command%20lines

Unfortunately I couldn't find anything about how it will behave if there's characters directly preceding the $, but systemd's handling of environment variables seems a likely culprit for the observed behavior requiring unix:${DOMAIN_SOCKET} instead of unix:$DOMAIN_SOCKET.

(It might also explain why for the uvicorn/ASGI example, both --uds $DOMAIN_SOCKET and --uds ${DOMAIN_SOCKET} work just fine, because there is not unix: prefix there.)

Yes, that's exactly it! We use systemd to launch your ASGI sites, and while Bash would interpret unix:$DOMAIN_SOCKET as containing an environment variable to expand, systemd gets confused if environment variables don't have whitespace on both sides.