log/syslog: reconnect on server restart

[gopherbot]

by akunokuroneko:

What steps will reproduce the problem?
1. Start go application using syslog
2. Send Log messages.
3. Restart syslog
4. Send more log messages

What is the expected output?
The messages from both 2 and 4

What do you see instead?
The messages from 2.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux

Which revision are you using?  (hg identify)
release.r59

Please provide any additional information below.

I've already looked at the source and identified the issue.  I will submit a fix once
I've had some time to work on it.

This is just incorrect behaviour in the syslog package - a quick check of the C
implementations shows that it handles connections more judiciously.

[adg]

Comment 1:

Status changed to Accepted.

[gopherbot]

Comment 2 by akunokuroneko:

patch against release with testcase. http://golang.org/cl/5078042/

Attachments:

1. syslog-auto-reconnect.diff (10664 bytes)

[rsc]

Comment 3:

Labels changed: added priority-later.

[rsc]

Comment 5:

Labels changed: added go1.1maybe.

[bradfitz]

Comment 6:

This issue was closed by revision 33995fe.

Status changed to Fixed.

[mattetti]

Comment 7:

Unfortunately this patch only allows for 1 retry, which is too short in case syslogger
is being restarted :(

[gopherbot]

Comment 8 by jeff.allen:

Yes, it is working as designed. The idea is that this standard library should ensure
that in the common case where the opened connection has "gone stale" because the syslog
server has been restarted hours or minutes or seconds before, the application will
refresh the connection and send the log message. But, being a piece of the standard
library, it should not be too heavy, and cover every possible kind of retry logic.
Instead, it should give a useful error that callers can use.
In the case where there's a race and the syslog client fails to write because the syslog
server is going down, then retries and fails, then the syslog server starts, Write will
return an error one time and the message will be lost. On the next call to Write, it
will reconnect and messages will be passed.
If you need to be absolutely, positively sure the message is logged, you can't use
syslog anyway, because the rest of the design of syslog servers is not usually 100%
safe. 
If you want to wait and retry when Write returns an error, you'd need to wrap calls to
Write to do that; but then you need to consider the impact this could have on callers to
Write, who might expect it to return immediately.
Hope this is helpful.