Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

log/syslog: should use ReportEvent api on Windows #1108

Closed
jpoirier opened this issue Sep 15, 2010 · 29 comments

Comments

Projects
None yet
8 participants
@jpoirier
Copy link
Member

commented Sep 15, 2010

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

This comment has been minimized.

Copy link

commented May 14, 2011

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

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2011

Comment 2:

Labels changed: added priority-later.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2011

Comment 3:

Labels changed: added priority-go1.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2012

Comment 4:

Owner changed to builder@golang.org.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jan 15, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2012

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

This comment has been minimized.

Copy link
Member

commented Jan 17, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Jan 17, 2012

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

This comment has been minimized.

Copy link
Member

commented Jan 18, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2012

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

This comment has been minimized.

Copy link
Member

commented Mar 15, 2012

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

This comment has been minimized.

Copy link
Contributor

commented May 28, 2012

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

This comment has been minimized.

Copy link
Member

commented Aug 6, 2012

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

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2012

Comment 16:

Labels changed: added go1.1maybe.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2013

Comment 17:

Labels changed: removed go1.1maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2013

Comment 18:

[The time for maybe has passed.]
@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 19:

Labels changed: added go1.2maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 20:

Labels changed: added feature.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 15, 2013

Comment 21:

Not much going on here. Moving to 1.3 maybe.

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

@kardianos

This comment has been minimized.

Copy link
Contributor

commented Aug 15, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2013

Comment 23:

Labels changed: removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 24:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 25:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 26:

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 27:

Labels changed: added repo-main.

@gopherbot

This comment has been minimized.

Copy link

commented Jan 27, 2014

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.

@jpoirier jpoirier added the repo-main label Jan 27, 2014

@mattn

This comment has been minimized.

Copy link
Member

commented Jan 16, 2015

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc added OS-Windows and removed priority-later labels Apr 10, 2015

@gopherbot

This comment has been minimized.

Copy link

commented Apr 25, 2015

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 1, 2015

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.

@bradfitz bradfitz closed this Dec 1, 2015

@golang golang locked and limited conversation to collaborators Dec 1, 2016

cirocosta referenced this issue in concourse/atc Aug 22, 2018

WIP
Signed-off-by: Bishoy Youssef <byoussef@pivotal.io>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.