Forum Moderators: phranque

Message Too Old, No Replies

Apache wont write to access_log

After I tried to erase it to start a new log file

         

wfernley

2:33 pm on Apr 25, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hey everyone,

I thought I would erase my access_log file to start fresh so I renamed the old one and created a new one and CHMOD'd it to 777. For some reason though Apache won't write to the access_log file. Even after I deleted the new file and renamed the old file back to its original filename of access_log it still wont write to even the old filename.

Can anyone help me out?

Thanks in advance for your help!

Wes

JohnKelly

5:57 pm on Apr 25, 2005 (gmt 0)

10+ Year Member



I have to restart apache on my server to get it to create new log files.

"service httpd restart" on the command line is how I do it.

moltar

6:14 pm on Apr 25, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Could be a permission problem too.

wfernley

6:19 pm on Apr 25, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Yeah it is very weird, Permissions seemed ok and I did restart apache. It all of a sudden started working, so I am very confused, but hey it is working now. Just wish I could understand why it would delay and then all of a sudden start working ;)

Thanks for the replies!

Wes

bluedalmatian

9:41 pm on Apr 25, 2005 (gmt 0)

10+ Year Member



Ive found it has to be restarted before it will write to new logs too.

jdMorgan

10:21 pm on Apr 25, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The likely cause of this is that logging to the access log is set up on a schedule. After you deleted the original log, it just took some time for the scheduler to re-write your log file (and possibly re-create it).

Jim

sitz

1:26 am on Apr 26, 2005 (gmt 0)

10+ Year Member



This may simply be result of a quirk^Wfeature in the way *nix works (of course, if you're running on win32, just ignore me =) ). If you delete a file from the filesystem, the application still has the file descriptor open; the file won't get closed until the application exits. When it starts back up, the file will get re-opened. This is a crucial thing to understand about *nix, since (sooner or later) *not* knowing it can bite you. =)

For instance, really strange things can happen if you gzip an open file; the application will continue to write to the file as though it were uncompressed. oy. =) As another extreme example, if you delete a file from the filesystem, and the application continues to write to the file descriptor for a REALLY long time, your disk will fill up. I mean, data's being written, right? However, if you search for disk for large files, you won't find the one that filled your disk, 'cause you deleted it. Once you bounce the application with that file descriptor open, *poof*. All your disk space comes back. =)

Note that you can see all the files that a given application has open using 'lsof' (available in source for from ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/, or (for linux/*bsd) in package form from your local package/ports respository.