urls.py not loading changes

2013-03-03 Thread Asier Hernández Juanes
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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.




Re: urls.py not loading changes

2013-03-08 Thread Asier Hernández Juanes
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!

El lunes, 4 de marzo de 2013 19:30:32 UTC+1, ke1g escribió:
>
> 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.
>
> On Mon, Mar 4, 2013 at 11:03 AM, Venkatraman S 
> > wrote:
>
>> 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.
>>
>>
>> On Mon, Mar 4, 2013 at 8:26 PM, Bill Freeman 
>> > wrote:
>>
>>> 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
>>>
>>> On Mon, Mar 4, 2013 at 9:03 AM, frocco >> >wrote:
>>>
>>>> That's good to know.
>>>>
>>>>
>>>> On Monday, March 4, 2013 8:12:15 AM UTC-5, Venkatraman.S. wrote:
>>>>
>>>>> Always prefer to delete the .pyc fie for issues such as these wherein 
>>>>> changes are not reflected despite server restart.
>>>>>
>>>>> On Sun, Mar 3, 2013 at 9:59 PM, Serge G. Spaolonzi 
>>>>> wrote:
>>>>>
>>>>>> 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<http://groups.google.com/group/django-users?hl=en>
>

Re: urls.py not loading changes

2013-03-08 Thread Asier Hernández Juanes
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?

El viernes, 8 de marzo de 2013 20:04:34 UTC+1, Javier Guerra escribió:
>
> On Sun, Mar 3, 2013 at 8:16 AM, Asier Hernández Juanes 
> > 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 
> > 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 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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.




Re: urls.py not loading changes

2013-03-09 Thread Asier Hernández Juanes
I understand but I cannot locate the FastCGI process to stop it. When I type 
"locate *.fcgi" I get no results at all so unfortunatelly I don't know how to 
stop the Django (or fastCGI) process itself.

Can anyone help me, please?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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.




Re: urls.py not loading changes

2013-03-09 Thread Asier Hernández Juanes
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/000:00:00 bash
18028 pts/000: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!

El sábado, 9 de marzo de 2013 15:22:07 UTC+1, Javier Guerra escribió:
>
> On Fri, Mar 8, 2013 at 6:14 PM, Asier Hernández Juanes 
> > 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 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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.




Re: urls.py not loading changes

2013-03-09 Thread Asier Hernández Juanes
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
uwsgi11916 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
uwsgi11917 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
uwsgi11918 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
uwsgi11975 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
uwsgi11976 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
uwsgi11977 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/000: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!

El sábado, 9 de marzo de 2013 16:19:58 UTC+1, Asier Hernández Juanes 
escribió:
>
> 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:5

Re: urls.py not loading changes

2013-03-11 Thread Asier Hernández Juanes
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!

El sábado, 9 de marzo de 2013 16:33:31 UTC+1, Asier Hernández Juanes 
escribió:
>
> 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
> uwsgi11916 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
> uwsgi11917 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
> uwsgi11918 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
> uwsgi11975 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
> uwsgi11976 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
> uwsgi11977 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/000: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!
>
> El sábado, 9 de marzo de 2013 16:19:58 UTC+1, Asier Hernández Juanes 
> escribió:
>>
>> 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: