[EMAIL PROTECTED] wrote:
> > Apache behaves similarly. If you send the parent process a SIGHUP or
> > SIGUSR1, it will close and reopen its log files. Note that with
> > SIGUSR1, any active children will still be writing to the old files.
> >
> > If Apache stops logging, one thing to try is
> >
> > kill -USR1 `cat /var/run/httpd.pid`
> >
> > (modify according to where you keep your pid file).
>
> I've gone so far as to kill -9 the server and restart it afresh several
> times. Unless there's some special property to USR1, I doubt it will work,
> but I'll be happy to try...
>
> <two minutes later>
>
> Whoa.. Umm... it worked! Ok, now I'm really confused. Like I said, I'd
> completely killed and restarted the server several times and it didn't
> work. What's so special about -USR1?
SIGUSR1 tells httpd to perform a `graceful' restart. The config files
are re-read, log files re-opened, any idle child processes are killed
and respawned, any busy child processes are allowed to complete the
current operation then restarted.
SIGKILL (`kill -9') kills the process stone dead, and may leave things
in a mess. I can't think of a specific reason why it should impact the
new httpd process, but it's something to be avoided where possible.
> There could be another reason why it
> worked. I'd just deleted and recreated the host last night out of
> desperation. I didn't think it would work because I used the same script
> that had created it in the first place. Sure enough it didn't log, but
> when I checked httpd.conf today I realized that, due to some changes we'd
> made earlier, that script didn't create a TransferLog entry. So that's why
> it didn't work last night. I created a TransferLog and did a kill -USR1
> and it worked. Which one made it work (and why it hadn't worked in the
> past since, again, I'm certain that the syntax in httpd.conf was correct)
> I don't know. Maybe someone can shed some light?
It is normal practice to specify TransferLog and ErrorLog directives
at the top-level (outside of any <VirtualHost> directives), as well as
for each virtual hosts. This should catch anything which doesn't apply
to a particular virtual host (i.e. every request will be logged
somewhere).
The absence of a TransferLog entry for the virtual host may well have
been the cause of the problem.
> > When you say `the access_log and error_log files are created by
> > apache', do you mean that it creates *all* of the log files for the
> > different domains, but doesn't write anything to any of them?
>
> Well, the problem's pretty much solved now, but for the sake of answering:
> No, I made a directory called /test and chmodded it 777. I then edited the
> virtualhost section for just one host that wasn't logging and set
> TransferLog /test/access_log and ErrorLog /test/error_log. When I
> restarted httpd, the empty /test directory suddenly contained access_log
> and error_log. So what I was saying was that Apache created new logging
> files when I gave them a new location. This told me that it was reading
> the httpd.conf file properly... and yet it still wouldn't log there.
If it creates a log file, but doesn't log to it, it would appear that
the <VirtualHost> directive isn't set up correctly (e.g. it's set up
for IP-based virtual hosts, but you don't have an IP address dedicated
to that domain, or that the DNS isn't correct), with the result that
the <VirtualHost> directive never matches any of the requests.
--
Glynn Clements <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]