On 01/18/2009 04:48 PM, Rainer Jung wrote: > On 18.01.2009 16:37, Ruediger Pluem wrote: >>
>>> >>> Step 6: >>> ------- >>> >>> open_error_log() calls >>> apr_file_close(s_main->error_log) >> >> The call to apr_file_close happens in ap_open_logs not in open_error_log >> and ap_open_logs is IMHO not called by piped_log_maintenance. > > Yes, sorry, it is ap_open_logs. > > But nevertheless: > > During startup or after restart we go through ap_open_logs() and thus > after startup or restart, the write side of the original pl is closed > and the pipe is written to via the duped FD in stderr. Ahh. Now I got it. So your approach seems fine. Really very confusing :-). > > More precisely ap_open_logs() calls open_error_log(), which returns > ap_piped_log_write_fd(pl) in s->error_log, and after return > ap_open_logs() calls apr_file_close(s_main->error_log) is s==s_main. > > When killing the logger, piped_log_maintenance() gets called. It can now > not simply use pl, because the write side has been closed before in > ap_open_logs(). > > I tried to keep the startup behaviour during restart, so I dup stderr to > the write side in the maintenance function, spawn and close the write > side again. > >>> FD10 gets closed, we only have FD2 and FD9 remaining, >>> ap_piped_log_write_fd(pl) is gone now! >>> >>> So if we want to keep this behaviour, we need to recreate the write side >>> of the pipe from stderr in maintenance before spawning again (in the >>> main error logger case), and close it after spawning. >>> >>> I tried using FD2 directly as the write side without duping it, but that >>> doesn't work. >> >> Hm. F10 should still be open and untouched. > > Just to make sure we are talking about the same. This gets only closed > for the main error logger. For all other error loggers and the access > loggers, there's no such complication. Yes, this clearly was only valid for the main error log. Regards Rüdiger
