2010/1/20 Pawel Tyll <[email protected]>: > On Jan 20, 3:45 am, Graham Dumpleton <[email protected]> > wrote: >> Rebuilding itself didn't help and when did rebuild it, didn't give me >> options menus for changing configuration anyway. > Try a 'make config' in port directory. Should work wonders for you ;) > >> Hopefully this gives me a test bed for tracking it down. > It does. > > Also I noted that socket was created with wrong owning user, but > correct group when defining user= and group= -
The socket isn't meant to have permissions matching daemon process. Has to have permissions which normal Apache server child processes running as Apache user can access as client. > and umask= was ignored > (or maybe it isn't used to set socket's permissions?). Maybe something > to look at? The socket permissions I see are 0700 and owner/group is www/wheel, which looks fine to me as owned by Apache user and group is probably what Apache was when started as root. What are the permissions you have? Anyway, it seems that apr_atomic_cas32() in APR libraries is broken on FreeBSD for some reason. That or the way I use it isn't quite right and although it works fine on other platforms, not on FreeBSD. Basically, the way of use it is as a faster way than a thread mutex of allowing only one thread into a critical section of code, but on FreeBSD it is just letting all threads through. They all then do poll() on listener socket and doing that either stuffs things up, or they all then go onto accept the connection when it comes and that fails. The apr_atomic_cas32() function is used in some of the Apache MPM modules so if it is broken, would expect Apache core to have issues as well. Graham
-- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
