Graham, Thanks for your help. I will try to gather more information (hopefully a full trace) for this over the weekend.
Sorry for being a bit "informal" on my responses. I had hoped this was a common issue, but as I have found it probably is not so common and depends upon a number of factors. Again, I will try to get more info soon. - JM On Jun 11, 5:45 pm, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > Since you never posted a full and complete traceback, we have no idea > what code is even triggering this condition, so how can we suggest > what needs to change. > > Also, you should do a 'ls -lasR' of /tmp/python.cache_root and work > out if all files under the directory are owned by the same or > different users. > > I also don't recollect you even explaining how you are hosting this. > Your problems could be how you have set up your hosting environment, > what user it runs as and what umask setting has been inherited by the > processes. > > Graham > > On Jun 12, 6:52 am, joshm <joshmat...@gmail.com> wrote: > > > > > This is a private beta...not production I have debug on for that > > reason. > > > In this instance, there are 2 django sites running, so this could very > > well be the issue. > > > They are being hosted on a vps but the production one has memcache > > setup as its cache backend, the beta site which is getting this error > > has none of that in its settings files, so it is defaulting to > > whatever django 1.0 defaults to. Is there a way to force the instance > > of django to not share this cache? > > > On Jun 9, 4:42 pm, Graham Dumpleton <graham.dumple...@gmail.com> > > wrote: > > > > Do you run more than one instance of Django on the same machine, > > > whether they be production or development systems? > > > > If you run multiple Django instances and they run as different users, > > > as would often be case where running development Django on same box > > > and production runs as Django, it is bad practice to put caches or > > > database in /tmp and use the same location for all instances. > > > > The situation that can arise if you do this is that another instance > > > could create directories/files which another instance cannot open or > > > create files within. Thus you get permission denied. > > > > So, more information is needed about how many Django sites you have > > > running, how they are hosted, what users they run as and how they are > > > configured for caches, databases etc. > > > > Graham > > > > On Jun 9, 3:23 am, jmat <joshmat...@gmail.com> wrote: > > > > > I'm getting an error using Django 1.0 when trying to log a new user > > > > in. When I call > > > > > login(request) > > > > > On a new user I will occassionally (not very often) get an error (the > > > > cache number values will be different): > > > > > Permission Denied: /tmp/python.cache_root/8/7/2 > > > > > Which is an: > > > > > OSError in /usr/lib/python2.4/os.py in makedirs, line 159 > > > > > I can't find any reference to /tmp/python.cache_root anywhere on my > > > > system, but it appears the call is originating from a django request. > > > > > I can temporarily fix the issue by enabling write permission on the > > > > given location, but down the road the same error seems to appear > > > > again... > > > > > Has anyone ever seen an error like this before? > > > > > any help will be appreicated. > > > > > - JM --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
