New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow disabling sendfile via an environment variable #1252
Comments
Are there already servesr that does something like it? In that case we may look at the environment variable they are using instead of using our own. Imo having smth "SENDFILE=no" would be better. thoughts? |
A cursory search does not reveal a typical environment variable for this purpose in other server software. I would be fine with |
Fixes the changelog bullets added for benoitc#1252, as well as a number of spelling corrections and markup improvements.
Fixes the changelog bullets added for benoitc#1252, as well as a number of spelling corrections and markup improvements.
Thank you for adding this! :-) |
add support for the `SENDFILE` environment variable. fix benoitc#1252
Fixes the changelog bullets added for benoitc#1252, as well as a number of spelling corrections and markup improvements.
Virtualbox has a bug where when using shared folders, the contents of a file transferred using sendfile can sometimes end up corrupted. A ticket for this issue has been open against Virtualbox for several years, but it still remains unfixed:
https://www.virtualbox.org/ticket/9069
https://www.virtualbox.org/ticket/12597
As a result, a pref was added to gunicorn to allow disabling:
http://docs.gunicorn.org/en/latest/settings.html#sendfile
However since
--no-sendfile
should only be used in local development environments, this means our in-repository wrapper scripts that invoke gunicorn need to be different for dev vs prod.To save having to add further complexity to these scripts (and to also help the case where someone invokes gunicorn directly rather than using the scripts), it would be great if a
GUNICORN_DISABLE_SENDFILE
environment variable (or similar) could be used instead. We'd then just define this only in the local Vagrant development environment's puppet scripts, leaving prod unaffected.If this is something that would be accepted, I'd be happy to open a PR. (I realise we can't just add environment variables for every single supported setting, but wasn't sure where the line lay, given things like #1205 were accepted.)
The text was updated successfully, but these errors were encountered: