Amazon + Django each 12 hours appears that [Errno 5] Input/output error

Question

I recently setup and deploy an Amazon EC2 instance for deploy my django project.

I was interacting with my application via browser when I get this error in the browser:

Answer 1

I have been exploring, and I should say that the origin of this error were in my code

I have two newbie errors:

1. print sentence in production

In the traceback that I shown above in my question, I had a print sentence inside my get_context_data() function of this way:

File "/home/ubuntu/workspace/neurorehabilitation-system/userprofile/views.py" in get_context_data
  50.             print (user.is_physiotherapist)

Is possible that each time that this print sentence is executed, the process try write to the stdout file in my amazon ec2 machine instance.

I remove this print sentence in that line, and retrieve the changes into my production servers via git and restart gunicorn server and all it's works perfect.

2. I have the DEBUG=True in production

I have the following settings files:

settings/
    base.py # --- without DEBUG
    development.py # --- DEBUG=True
    testing.py # --- DEBUG=True
    production.py # --- DEBUG=False
    staging.py # --- DEBUG=False  

All files (development.py, testing.py, production.py, staging.py) inherit from base.py

But I don't know how to make that in my ec2 instance, the production.py be executed, this inherit all from base.py and override DEBUG to False.

I've been exploring and one possibility is change their value (True or False) according to the name of the host in which is running my application, such as shown in this post

In my case this is the value of my hostname

(nrb_dev)ubuntu@ip-172-31-27-249:~$ python
Python 3.4.3 (default, Oct 14 2015, 20:28:29) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> a=socket.gethostname()
>>> a
'ip-172-31-27-249'
>>> 
>>> if a != 'ip-172-31-27-249':
...     DEBUG = print ('Caleno juiciocito')
... 
>>> DEBUG
True
>>> 

This mean, put into my base.py the following:

import socket

if socket.gethostname() == 'ip-172-31-27-249':
    DEBUG = False
else:
    DEBUG = True

Although I am hardcoding the hostname of the production server in my code. This mean that I am adding a point thar after will have modified manually when we want deploy my project in other machine with other hostname

Is this a best practice despite to it's works?

Another option which I think that it's the most suited alternative is fix the value of my DJANGO_SETTINGS_MODULE environment variables

In my particular situation I am using virtualenvwrapper and I have two virtual environments so:

nrb_dev for my development environment

nrb_test for my testing environment . I have some hooks which are activated when the virtual environments are activated

In nrb_dev in $VIRTUAL_ENV/bin/postactivate I have this:

export DJANGO_SETTINGS_MODULE="neurorehabilitation.settings.development"

In the same way, in nrb_test in $VIRTUAL_ENV/bin/postactivate I have this:

export DJANGO_SETTINGS_MODULE="neurorehabilitation.settings.testing"

This mean that in my amazon EC2 production machine I should change the hook in $VIRTUAL_ENV/bin/postactivate to choose the settings/production.py of this way:

export DJANGO_SETTINGS_MODULE="neurorehabilitation.settings.production"

Just for test effects and the temporal way, I print the DEBUG value in my settings/production.py

from .base import *

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = False
print (DEBUG) # just for now.

And when I start my gunicorn daemon server, I can see that DEBUG value is set to False

(nrb_dev)ubuntu@ip-172-31-27-249:~/workspace/neurorehabilitation-system$ gunicorn -c neurorehabilitation/gunicorn_config.py neurorehabilitation.wsgi 
[2016-01-08 00:26:15 +0000] [6691] [INFO] Starting gunicorn 19.4.5
[2016-01-08 00:26:15 +0000] [6691] [INFO] Listening at: http://127.0.0.1:8000 (6691)
[2016-01-08 00:26:15 +0000] [6691] [INFO] Using worker: sync
[2016-01-08 00:26:15 +0000] [6694] [INFO] Booting worker with pid: 6694
False
^C[2016-01-08 00:26:19 +0000] [6691] [INFO] Handling signal: int

Additional Notes

I can explore the Django Logging functionality for register events and others things of my application.

I should explore the supervisor service for manage the gunicorn procees of a better way in production.

Other resources for supervisor:

How to install and manage supervisor in Ubuntu

Setting up Django with Nginx, Gunicorn, virtualenv, supervisor and PostgreSQL

Answer 2

some possible causes and suggestions for this problem.

Causes:

1. circular references
2. hard disk bad sector error
3. complex process, user, network, permission and other raise mixed error

Suggestions:

1. use logging replace print, it is best way!!!
2. redirect IO to a file or to null: python test.py > test.log 2>&1 &, python test.py > /dev/null 2>&1 &

Answer 3

File "./my_api/to/Credit.py", line 17, in get_credit_from_response

print xml_response

The stack trace is clear enough. You have a function named get_credit_from_response - inside it the I/O Error is happening. It is probably scheduled every 6/12 hours and causes the issue. Please double check your code.