On 25/11/2010, at 02:05, David Taylor wrote: > On 25/11/10 12:01, David Taylor wrote: >> On 25/11/10 11:46, David Taylor wrote: >>> On 25/11/10 01:11, Alvaro Lopez Ortega wrote: >>>> On 24/11/2010, at 15:06, David Taylor wrote: >>>> >>>>> I have configured www.mydomain.com. While cherokee is running normally, >>>>> I cannot visit www.mydomain.com. However, if I stop cherokee and >>>>> manually run cherokee-worker from the command line, www.mydomain.com >>>>> miraculously starts to work. >>>>> >>>> Looks like you might have two different Cherokee deployments interfering >>>> each other. The following command might shed some light on it: >>>> >>>> find /usr \( -name cherokee -o -name cherokee-worker \) -a -type x -print >>> >>> r...@linode:~# find /usr \( -name cherokee -o -name cherokee-worker \) -a >>> -type f -executable -print >>> /usr/sbin/cherokee-worker >>> /usr/sbin/cherokee >>> r...@linode:~# >>> >>> [...] >>> Today I seem to be getting slightly different behaviour, but still "broken" >>> behaviour. >> >> I spoke too soon. It's back to the same behaviour. If I do >> "/etc/init.d/cherokee stop" and run "cherokee-worker" manually, the site >> serves fine. If I kill "cherokee-worker" and do "/etc/init.d/cherokee >> start" I get a 404. All other sites work fine. There's nothing in the >> error logs. >> >> I assumed it might be something to do with permissions, because >> cherokee-worker is running as root when I run it manually. But the site is >> www-data:www-data on every directory and file, with 755 permissions. It's >> linked to by a symbolic link, but that link also has the same ownership and >> permissions. >> > > Actually, it looks like cherokee-worker drops privileges automatically when I > run as root, so that's not it either.
There is a fundamental difference between launching cherokee and cherokee-worker as root. When you launch cherokee there is a little process (cherokee) that will keep root privileges. That process will spawn a cherokee-worker process that will drop the root permissions. In this case, when an interpreter (php, django, ror, ..) is launched, it's done through the main cherokee process, so it can be launched under a different UID. In case you launch cherokee-worker by hand, it won't be able to communicate with its parent process, so it will try to launch the interpreters by it owns, under the same UID. Having that in mind, it looks like the problem could be related to permissions. One of the back-end apps could be failing to read a file and returning those 404 errors, for instance. You could try to enable CHEROKEE_TRACE¹ and set it to all. It might print something interesting. 1.- http://www.cherokee-project.com/doc/dev_debug.html -- Octality http://www.octality.com/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
