Gaah, this is ugly.
--

Hi,
I have no idea, but it seems to fix a real issue.
Ciao,

Dscho
--

On Mon, Apr 28, 2008 at 07:08:50PM +0100, Johannes Schindelin <Johannes.Sch=
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?
Mike

--

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.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

--

Hi,
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?
Ciao,

Dscho
--

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

--

Hi,
This is sysklogd from Ubuntu, compiled for amd64.  The timestamp on

/dev/log is older than a month.
Thanks,

Dscho
--

Recreating the socket should not cause this to happen either, because

the git-daemon will still hold on to the old inode (even after the file
I'd still recommend trying to reproduce the problem, then find out which

filedescriptor/file the close is hanging on.

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--

Hi,
I have no idea, but other programs must have the same problem.  I should

have shown some diligence and researched that.  Will do so now.
Ciao,

Dscho
--

On Mon, Apr 28, 2008 at 07:37:54PM +0100, Johannes Schindelin <Johannes.Sch=
I don't say that just one example justifies me, but here is an example:

icald (google://openlog+sighup 2nd result) does this.

It could, but that's the reason one uses the openlog(3) interface to

syslog, to centralise logfilemanagement and *not* having to deal with

the intricacies of logfile rotation and the like.  So it doesn't need

to.  When you need logfile rotation, you're better off with using

openlog(3), and doing that the proper way means *NOT* closing and
They don't.  Your patch fixes the wrong problem.  Please don't fix
N.B. I've never had to close and reopen the openlog(3) syslog interface

in any of the daemons I've written.

The example you refer to of icald is where it directly writes to a

logfile, which is *not* what this patch was about, so please do not use

it as justification.

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--

Hi,
since you seem to be very new to this list: we really appreciate a

Reply-to-all here.
So do you have any ideas what is happening there?  It seems that after

logrotate does its thing, syslog() is stuck in the close() call.
Any constructive help is very much appreciated.
Ciao,

Dscho
--

I see.  I normally consider that bad form (maybe my age shows ;-);
Erm, just so I understand the problem:

- git-daemon is configured to use syslog(3) to log

- git-daemon uses openlog(3)

- git-daemon logs happily for a while

- rotatelog rotates logfiles in /var/log and communicates with syslogd

  to make sure syslogd starts new logfiles in /var/log

- And then git-daemon hangs on which system/library call?

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--

Hi,
It seems that this happens, yes.
Ciao,

Dscho
--

Could you hang an strace off of git-daemon and check what system call it

hangs on at that point in time?

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--

Hi,
I can do better than that.  I attached to the process, and like I said, it

hung in close().
Ciao,

Dscho
--

On which descriptor?  (I.e. what does the descriptor point to?)

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--

Hi,
Sorry, that I don't remember, but I strongly suspect the syslog

descriptor, since the backtrace showed "syslog()" a few levels up of

close().
Ciao,

Dscho
--

AFAICT, sending SIGHUP to syslogd doesn't cause the /dev/log pipe to be

closed, therefore there shouldn't be any closing of that /dev/log pipe.

So if you can reproduce it, please report which filedescriptor it is

trying to close.

--

Sincerely,                                                          srb@cuci.nl

           Stephen R. van den Berg.

--

Hi,
Probably.  But I do not understand how git-daemon just hangs when trying

to close() something from within syslog().  Maybe my analysis is

completely wrong, and I should do something completely different.
Ciao,

Dscho
--