Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign uplog/syslog: should use ReportEvent api on Windows #1108
Comments
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
May 14, 2011
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 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Owner changed to builder@golang.org. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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. <<< |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Jan 27, 2014
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
added
accepted
labels
Jan 27, 2014
jpoirier
added
the
repo-main
label
Jan 27, 2014
This comment has been minimized.
This comment has been minimized.
rsc
added this to the Unplanned milestone
Apr 10, 2015
rsc
added
OS-Windows
and removed
priority-later
labels
Apr 10, 2015
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Apr 25, 2015
CL https://golang.org/cl/2953 mentions this issue. |
This comment has been minimized.
This comment has been minimized.
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
closed this
Dec 1, 2015
bradfitz
referenced this issue
Jan 4, 2016
Closed
log/syslog : support tcp/udp for non-linux platforms #13810
golang
locked and limited conversation to collaborators
Dec 1, 2016
gopherbot
added
the
FrozenDueToAge
label
Dec 1, 2016
referenced
this issue
in concourse/atc
Aug 22, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
jpoirier commentedSep 15, 2010