On 02/14/2011 01:49 AM, Tomas Doran wrote:
Perhaps there's a permission problem but, in an effort to figure this
out, I have set everything at the site's "root," web, to 777 and
everything in the scripts directory to 777, too.
Start apache with one child using strace -f
Watch what's actually crapping out?
Wow. First time I've ever done that. Interesting to see how @INC gets
walked.
This looked suspicious to me:
3969 stat64("/tmp/sumo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
3969 stat64("/tmp/sumo/session_data", {st_mode=S_IFREG|0640,
st_size=5832704, ...}) = 0
3969 stat64("/tmp/sumo/session_data", {st_mode=S_IFREG|0640,
st_size=5832704, ...}) = 0
3969 stat64("/tmp/sumo/session_data", {st_mode=S_IFREG|0640,
st_size=5832704, ...}) = 0
------------
3969 open("/tmp/sumo/session_data", O_RDWR|O_LARGEFILE) = -1 EACCES
(Permission denied)
------------
3969 write(2, "Couldn't load class (Sumo) becau"..., 1375) = 1375
From here, what happens looks connected with logging an access event.
Here are the /tmp/sumo/session_data permissions:
[root@mayfly sumo]# pwd
/tmp/sumo
[root@mayfly sumo]# ls -l
total 5708
-rw-r----- 1 root root 5832704 Feb 12 18:10 session_data
[root@mayfly sumo]#
A permission problem with writing to the /tmp/sumo directory makes sense
of the fact that the standalone server works but apache doesn't.
Perhaps because I run the standalone server (and myapp_fastcgi.pl) from
the command line as root and apache runs them as some other user? I
wonder which is trying to write and where the system expects to write
temp files?
If you know a way to figure it out from here, I'd be grateful, but at
least I have a promising new path -- I do, don't I?
Thanks!
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
