log/syslog: should use ReportEvent api on Windows

[jpoirier]

What steps will reproduce the problem?
1. run "make test" from src/pkg/syslog

What is the expected output? What do you see instead?
The test should pass. The test fails.

[gopherbot]

Comment 1 by paulo.jpinto:

A good idea for Windows might be to map the syslog API to the Event Log system.
There are a few caveats:
1 - The fix for issue #1552 (https://golang.org/issue/1552) is a
requirement. Some resource strings are need to be embedded on the executable.
2 - The API has changed between Windows 2000/XP and Windows Vista.
An example for Windows 2000/XP is visible at
http://msdn.microsoft.com/en-us/library/aa363680%28v=VS.85%29.aspx
The new Event API (after Windows Vista) is described at
http://msdn.microsoft.com/en-us/library/aa385780%28v=VS.85%29.aspx

[rsc]

Comment 2:

Labels changed: added priority-later.

[rsc]

Comment 3:

Labels changed: added priority-go1.

[robpike]

Comment 4:

Owner changed to builder@golang.org.

[alexbrainman]

Comment 5:

This facility is unix specific. Does not exists on Windows.
The client portion of this package could be useful, if someone on Windows wants to
report to syslog on another unix computer.
Alternatively, this could be a start for a general log package, that reports to "system"
log. But, I am not sure, it is a good time to start such development now.
Alex

[rsc]

Comment 6:

The idea of writing to the system log is not Unix-specific,
although the API may have gotten a little Unixy.
On Windows, I think it would make sense for this package
to be implemented and to use ReportEvent.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363679(v=vs.85).aspx
Russ

[alexbrainman]

Comment 7:

I have 2 reservations about this idea.
Current syslog implementation could be used on Windows to post messages to a unix
computer over the network. I don't want this functionality to be masked by something
else.
As far as I know, ReportEvent facility is supposed to be used by "service" type
applications (http://www.commsoft.com/services.html) only. These do not have console to
report errors, so it is the only way for them to be visible. Another issue, I could be
wrong here, but as far as I know, ReportEvent require strategically placed on disk
resources (dll/exe/...) to function. See http://goo.gl/ced5T for more details, but,
simply speaking, ReportEvent uses dwEventID (an int) that is just a reference to a
format string that must live in some permanent file. Event viewer program will need
resource file to be present all the time to display error messages properly. For
"service" programs, these format strings are normally part of service exe file - once
"installed" at a particular location, it is always present.
Alex

[rsc]

Comment 8:

The Plan 9 implementation of syslog will not support writing
to Unix logs.  I do not expect the Windows implementation to
support it either.  The idea was to make it write to the appropriate
local system log, no matter what the system.
Russ

[alexbrainman]

Comment 9:

That is cool. I am not sure when I will have time to have a go at it.

Labels changed: added os-windows.

[rsc]

Comment 12:

I will send out a CL to disable this package on Windows.
We can update it later.

Labels changed: added priority-later, removed priority-go1.

[alexbrainman]

Comment 13:

For future reference. As suggested by kardia. We could use EventMessageFile of
%SystemRoot%\System32\EventCreate.exe to display our messages reported by ReportEvent
Windows api.
>>>
Try merging the following in:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\GoServiceTest2]
"EventMessageFile"="%SystemRoot%\\System32\\EventCreate.exe"
"TypesSupported"=dword:00000007
"CustomSource"=dword:00000001
The event ID must be greater then zero, but, having these registry
entries in the service you register appears to do the trick.
<<<

[kardianos]

Comment 14:

After thinking about this for a while, I think the log/syslog package should simply use
the ReportEvent api without writing to the registry. This will prefix every event with a
default message, but I really don't think the log package by itself should alter the
registry in normal runtime. The Registry entry is so flat and there's a decent chance
you will overwrite a different service name. Also, a running program may be run with
lower permissions then what is required to modify the registry at runtime. 
When running a program as a service (daemon) on windows, I have to "Install" it anyway,
that is when the registry should be modified.
Embedded resource strings don't have much to do with this issue. The main issue is
creating the registry entries that point to the resource strings, and as pointed out
above, this can be any pre-existing executable.

[alexbrainman]

Comment 15:

I have written a package recently that provides access to windows event log. See the
docs for it http://go.pkgdoc.org/code.google.com/p/winsvc/eventlog. Perhaps, I could use
my code in log/syslog.
Unfortunately, the api is different. Also code.google.com/p/winsvc/eventlog provides for
"event message file" installation, so event log entries look presentable. For example,
simple "error" message looks like:
>>>
The description for Event ID ( 3 ) in Source ( mylog ) cannot be found. The local
computer may not have the necessary registry information or message DLL files to display
messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve
this description; see Help and Support for details. The following information is part of
the event: error.
<<<
without "event message file".
@Russ, if you still wants to proceed with this plan, please, let me know how you want to
fit code.google.com/p/winsvc/eventlog into log/syslog.
Alex

[rsc]

Comment 16:

Labels changed: added go1.1maybe.

[robpike]

Comment 17:

Labels changed: removed go1.1maybe.

[rsc]

Comment 18:

[The time for maybe has passed.]

[rsc]

Comment 19:

Labels changed: added go1.2maybe.

[rsc]

Comment 20:

Labels changed: added feature.

[robpike]

Comment 21:

Not much going on here. Moving to 1.3 maybe.

Labels changed: added go1.3maybe, removed go1.2maybe.

[kardianos]

Comment 22:

I'm sure Alex or I could get a CL in if we got an approved direction for this. Otherwise
we should close this and document this is unix syslog only.

[robpike]

Comment 23:

Labels changed: removed go1.3maybe.

[rsc]

Comment 24:

Labels changed: added go1.3maybe.

[rsc]

Comment 25:

Labels changed: removed feature.

[rsc]

Comment 26:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 27:

Labels changed: added repo-main.

[gopherbot]

Comment 28 by ccpaging:

There is another syslog for windows. http://syslog-win32.sourceforge.net
And running OK on Windows XP machine. 
At least, the go program may send the logger message to another UNIX syslog by TCP.

[mattn]

https://go-review.googlesource.com/#/c/2953/

[gopherbot]

CL https://golang.org/cl/2953 mentions this issue.

[bradfitz]

It was probably a mistake to include log/syslog in the standard library instead. Let's develop this elsewhere, instead. It doesn't need to live in the standard library.