Re: urls.py not loading changes

299 views
Skip to first unread message

Serge G. Spaolonzi

unread,
Mar 3, 2013, 11:29:20 AM3/3/13
to django...@googlegroups.com
Maybe the server is loading an old .pyc file. try to delete the urls.pyc file and restart the server. 

On Sun, Mar 3, 2013 at 11:16 AM, Asier Hernández Juanes <asier...@gmail.com> wrote:
Hi everyone,

i have a remote Linux server with a Django application running in a nginx server but when I make a change in urls.py like adding a new urlpattern the server is not applying the changes. I have restarted nginx server but the new url is not loading.

Does anyone know what may be the problem?

Thanks a lot!

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Serge G. Spaolonzi
Cobalys Systems

Venkatraman S

unread,
Mar 4, 2013, 8:12:15 AM3/4/13
to django...@googlegroups.com
Always prefer to delete the .pyc fie for issues such as these wherein changes are not reflected despite server restart.

frocco

unread,
Mar 4, 2013, 9:03:03 AM3/4/13
to django...@googlegroups.com
That's good to know.

Bill Freeman

unread,
Mar 4, 2013, 9:56:39 AM3/4/13
to django...@googlegroups.com
This should not be a .pyc problem, since upon startup python compares the modified time of the .pyc to that of the .py, if available.

python will use the .pyc if it can't see the .py .  I don't know what it will do if the .py is there, but it doesn't have permission to read it (possible permissions issue).

The other way this could be a .pyc problem is if the .py file was updated in such a way that the modified time is left older than that of the .pyc (differences in time setting on the two machines, some funky transfer mechanism that sets the target modified time to match that of the source, where the .pyc is newer, or the machine time was messed up the first time the app was started, yielding a .pyc modified time far in the future).

When I've had troubles like this it has more often been that I've had two copies of the site on the deployment box, and I've been fixing the wrong one.

Bill

Venkatraman S

unread,
Mar 4, 2013, 11:03:41 AM3/4/13
to django...@googlegroups.com
Well, it so happens that when you ftp the file from your local box to a remote machine the timezones are mostly different. For eg. i am in India and we are 'ahead' of the US, so when i push my code to a server in US timezone, i see this problem most often.

Bill Freeman

unread,
Mar 4, 2013, 1:30:32 PM3/4/13
to django...@googlegroups.com
Yes.  So it is best to select transfer mechanisms that set the modified time of the .py file to the target machine's current time at the moment that the newly written copy is closed, rather than caring about the modified time on the source machine.

Most mechanisms do this by default (cp, mercurial checkout/update, tar).  You usually have to go out of your way to get the modified (and created and accessed time) reflected from the source to the target.  If doing that, don't.  If your mechanism preserves modified time by default (maybe rsync?) see if you can't surpress it.  Or "touch" the file after transfer.

Asier Hernández Juanes

unread,
Mar 8, 2013, 12:14:17 PM3/8/13
to django...@googlegroups.com
I have removed the .py and the .pyc files, restart the nginx server and the application is still working.

I think the alication is being cached or I have the application duplicated but I am not able to find the solution.

Some ideas?

Thanks!

Javier Guerra Giraldez

unread,
Mar 8, 2013, 2:04:34 PM3/8/13
to django...@googlegroups.com
On Sun, Mar 3, 2013 at 8:16 AM, Asier Hernández Juanes
<asier...@gmail.com> wrote:
> i have a remote Linux server with a Django application running in a nginx
> server

Django application's don't run in the nginx server. There must be
some other process running your app. Either uWSGI, gunicorn, FastCGI,
etc.


On Fri, Mar 8, 2013 at 12:14 PM, Asier Hernández Juanes
<asier...@gmail.com> wrote:
> I have removed the .py and the .pyc files, restart the nginx server and the
> application is still working.

you have to restart the Django process to make it reload the new code.


--
Javier

Asier Hernández Juanes

unread,
Mar 8, 2013, 3:11:42 PM3/8/13
to django...@googlegroups.com
Maybe fastCGI but when I stop the nginx server with /etc/init.d/nginx stop the application is not loading.

I have seen some fastCGI configuration inside nginx server but I don't know how to restart fastCGI process or Django process itself.

How can I do that?

Bill Freeman

unread,
Mar 8, 2013, 4:53:36 PM3/8/13
to django...@googlegroups.com
Well, nginx is a proxy to the fastCGI application.  So you can't access it from the usual URL when
nginx is stopped, but that doesn't mean that the process to which you proxy, which is running
Django, has stopped.

--
Message has been deleted

Javier Guerra Giraldez

unread,
Mar 9, 2013, 9:22:07 AM3/9/13
to django...@googlegroups.com
On Fri, Mar 8, 2013 at 6:14 PM, Asier Hernández Juanes
<asier...@gmail.com> wrote:
> When I type "locate *.fcgi" I get no results at all


that searches for files. no relation to processes.

to help you, first we need to know a bit about your deployment
architecture, specially which WSGI server you're using behind nginx.

for FastCGI, one easy to use is flup. it can be started using the
Django manage.py script:

# python manage.py runfcgi

another popular choice is a fast python http server, like gunicorn.

in either case, it's usually not started from the command line, but
from a startup script. also, most of these scripts don't run directly
the server, but use some daemon monitor. like supervisord, or
start-stop-daemon.

as you see, there are lots of options

so, which is your case? which steps you did to install your app?


--
Javier

Asier Hernández Juanes

unread,
Mar 9, 2013, 10:19:58 AM3/9/13
to django...@googlegroups.com
The problem is that I am administrating this server where the Django application was already installed and deployed so I don't have this information.

However I have execute "ps -e" to view all the processes running on my server and I got this:

  PID TTY          TIME CMD
    1 ?        00:00:25 init
    2 ?        00:00:00 kthreadd
    3 ?        00:03:02 ksoftirqd/0
    5 ?        00:00:00 kworker/u:0
    6 ?        00:00:00 migration/0
    7 ?        00:08:20 watchdog/0
    8 ?        00:00:00 cpuset
    9 ?        00:00:00 khelper
   10 ?        00:00:00 kdevtmpfs
   11 ?        00:00:00 netns
   12 ?        00:00:27 sync_supers
   13 ?        00:00:00 bdi-default
   14 ?        00:00:00 kintegrityd
   15 ?        00:00:00 kblockd
   16 ?        00:00:00 ata_sff
   17 ?        00:00:00 khubd
   18 ?        00:00:00 md
   19 ?        00:05:58 kworker/0:1
   21 ?        00:00:02 khungtaskd
   22 ?        00:05:22 kswapd0
   23 ?        00:00:00 ksmd
   24 ?        00:00:00 fsnotify_mark
   25 ?        00:00:00 ecryptfs-kthrea
   26 ?        00:00:00 crypto
   35 ?        00:00:00 kthrotld
   36 ?        00:00:00 scsi_eh_0
   37 ?        00:00:00 scsi_eh_1
   40 ?        00:00:00 binder
   41 ?        00:00:00 kworker/u:4
   60 ?        00:00:00 deferwq
   61 ?        00:00:00 charger_manager
   62 ?        00:00:00 devfreq_wq
  236 ?        00:03:50 jbd2/sda3-8
  237 ?        00:00:00 ext4-dio-unwrit
  353 ?        00:00:00 upstart-udev-br
  391 ?        00:00:00 kjournald
  395 ?        00:00:00 udevd
  541 ?        00:00:03 dbus-daemon
  554 ?        00:00:00 udevd
  555 ?        00:00:00 udevd
  563 ?        00:00:00 vballoon
  572 ?        00:08:35 rsyslogd
  577 ?        00:00:00 kpsmoused
  597 ?        00:00:00 kworker/0:2
  730 ?        00:00:01 upstart-socket-
  739 ?        00:01:17 sshd
  832 tty4     00:00:00 getty
  838 tty5     00:00:00 getty
  862 tty2     00:00:00 getty
  863 tty3     00:00:00 getty
  869 tty6     00:00:00 getty
  880 ?        00:00:00 acpid
  885 ?        00:00:14 cron
  887 ?        00:00:00 atd
  990 ?        00:00:02 mdadm
 1015 ?        00:00:21 chronyd
 7034 tty1     00:00:00 getty
 7890 ?        00:01:35 flush-8:0
 9790 ?        00:00:26 master
 9794 ?        00:00:04 qmgr
 9806 ?        00:00:03 tlsmgr
11916 ?        00:03:52 uwsgi
11917 ?        00:08:18 uwsgi
11918 ?        00:06:14 uwsgi
11975 ?        00:03:57 uwsgi
11976 ?        00:02:19 uwsgi
11977 ?        00:01:50 uwsgi
11984 ?        00:00:00 nginx
11985 ?        00:00:03 nginx
11986 ?        00:00:06 nginx
17773 ?        00:00:00 pickup
17788 ?        00:00:00 sshd
17969 pts/0    00:00:00 bash
18028 pts/0    00:00:00 ps
18065 ?        00:54:38 mysqld


I think the key process is uwsgi but I can't find he way to restart it if is this the process tha I need to restart.

How do you think?

Thanks again!

Asier Hernández Juanes

unread,
Mar 9, 2013, 10:33:31 AM3/9/13
to django...@googlegroups.com
I have launched a "/etc/init.d/uwsgi restart" but the application is still not loading the changes in urls.py file.

I think I have to kill the process because after restarting the uwsgi process the PID is still the same:

root@miami ~ # ps -fea|grep uwsgi
uwsgi    11916     1  0 Jan22 ?        00:03:52 uwsgi --uid uwsgi --home /home/oper/bros --pythonpath /home/oper/bros/src --socket 127.0.0.1:5001 --chmod-socket --module wsgi -b 8192 --logdate --optimize 2 --processes 2 --master --logto /home/oper/bros/log/uwsgi.log
uwsgi    11917 11916  0 Jan22 ?        00:08:19 uwsgi --uid uwsgi --home /home/oper/bros --pythonpath /home/oper/bros/src --socket 127.0.0.1:5001 --chmod-socket --module wsgi -b 8192 --logdate --optimize 2 --processes 2 --master --logto /home/oper/bros/log/uwsgi.log
uwsgi    11918 11916  0 Jan22 ?        00:06:15 uwsgi --uid uwsgi --home /home/oper/bros --pythonpath /home/oper/bros/src --socket 127.0.0.1:5001 --chmod-socket --module wsgi -b 8192 --logdate --optimize 2 --processes 2 --master --logto /home/oper/bros/log/uwsgi.log
uwsgi    11975     1  0 Jan22 ?        00:03:57 uwsgi --uid uwsgi --home /home/oper/fys --pythonpath /home/oper/fys/src --socket 127.0.0.1:5002 --chmod-socket --module wsgi -b 8192 --logdate --optimize 2 --processes 2 --master --logto /home/oper/fys/log/uwsgi.log
uwsgi    11976 11975  0 Jan22 ?        00:02:19 uwsgi --uid uwsgi --home /home/oper/fys --pythonpath /home/oper/fys/src --socket 127.0.0.1:5002 --chmod-socket --module wsgi -b 8192 --logdate --optimize 2 --processes 2 --master --logto /home/oper/fys/log/uwsgi.log
uwsgi    11977 11975  0 Jan22 ?        00:01:50 uwsgi --uid uwsgi --home /home/oper/fys --pythonpath /home/oper/fys/src --socket 127.0.0.1:5002 --chmod-socket --module wsgi -b 8192 --logdate --optimize 2 --processes 2 --master --logto /home/oper/fys/log/uwsgi.log
root     18451 17969  0 16:30 pts/0    00:00:00 grep --color=auto uwsgi


Some clue to restart uwsgi process. I know how to kill it but what is the best way to restart it?

Thanks!

Asier Hernández Juanes

unread,
Mar 11, 2013, 3:07:23 PM3/11/13
to django...@googlegroups.com
I found a solution!

I created a file /tmp/django.pid with the PID of the UWSGI master-process, then I executed in the shell the command  uwsgi-core --reload /tmp/django.pid and the UWSGI process has restarted and the urls.py changes are working now.

Thanks a lot for the help!
Reply all
Reply to author
Forward
0 new messages