Johannes Schindelin wrote:
quoted text
> Hi,
> 
> On Tue, 29 Apr 2008, Andreas Ericsson wrote:
> 
>> Mike Hommey wrote:
>>> On Mon, Apr 28, 2008 at 08:21:14PM +0200, Miklos Vajna wrote:
>>>> On Mon, Apr 28, 2008 at 07:08:50PM +0100, Johannes Schindelin
>>>> <Johannes.Schindelin@gmx.de> wrote:
>>>>>>> With rotating logs, there is a problem when the syslog is opened
>>>>>>> only once (in the beginning).  So open the log everytime we write
>>>>>>> something, and close it directly after writing.
>>>>>> Gaah, this is ugly.
>>>>>>
>>>>>> Is this something all the daemons need to deal with?
>>>>> I have no idea, but it seems to fix a real issue.
>>>> logrotate supports sending a signal (typically SIGHUP) to the process
>>>> after it rotated the log. Couldn't we just re-open the log on SIGHUP?
>>> Isn't the problem that git-daemon loses its connection to the syslog
>>> daemon when logrotate sighups syslog?
>>>
>> It really shouldn't. The connection to the syslog daemon is just a
>> unix socket (/dev/log) which is used to send whatever passes for
>> UDP packets on unix domain sockets. Since the socket isn't re-created
>> by syslogd (well, a sane syslogd anyways), but rather just open()'ed
>> for reading, no program should ever need to reconnect.
> 
> What can I say?  The problem just went away with my workaround.  Is it 
> possible that I have to catch SIGHUP, and closelog() && openlog()?  But 
> why do other daemons seem to not have that problem at all?
> 

Other daemons don't get SIGHUP'ed when logs are rotated. I think something
else is going on there.

What syslogd are you using? Perhaps it insists on re-creating the socket.
That might cause the behaviour you're seeing, but then you should probably
see it in a ton of other daemons as well.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html