Closed bocca closed 11 months ago
ATOMIC_APPEND
has been possible in .NET (Core) for a few versions now, I think we'd be better off enabling that feature and taking the necessary NUPKG dependency on the versions that support it.
(Changing access rights to the mutex would probably need a breaking change, since it would allow a low-privilege user to disrupt logging by a higher-privileged user by taking and never releasing the mutex.)
I have tested ATOMIC_APPEND
and added some comments and code in #221.
Thanks!
Closing on the basis that #221 can track the issue/need If this is incorrect and there is something separately actionable here, I'm not opposed to having an issue; I just don't see what it is...
In some cases, the second process trying to open a shared file (
shared: true
) throws exception on mutex creation, and no log events are registered. This is registered inSelfLog
:The documentation for System.Threading.Mutex says
My enviroment is: ASP.NET Core 6 app hosted in IIS in-process in Windows Server 2012 R2 (I know, it's old). I deploy using Blue/Green deployment applied to the apppool level, that is, for a small period of time, I have two appools simultaneously trying to log to the same file.
In .NET Framework, there is a
Mutex
constructor that accepts anMutexSecurity
with an ACL to specify theFullControl
permission required. In .NET Core there is no such construtor, but instead the methodMutexAcl.Create
inSystem.Threading.AccessControl
nuget package can be used. This way of creating the mutex, posted in NLog issue #5244, resolves the problem:I have tested it, replacing the mutex creation in
SharedFileSink.OSMutex.cs
, and it worked for me.In case of .NET Core, using
MutexAcl.Create
adds a dependency toSystem.Threading.AccessControl
package. If that is not desirable, I suggest to include a way to pass to Serilog a factory method to create mutexes, and talk about the problem and solution in the documentation of Shared log files.