Windows microservice created from .net core using does not write logs to path

[seheri]

I have created a windows service from c# .net core which uses Serilog.Sinks.Async.File in appsettings.json as below

"Serilog": { "Using": [ "Serilog.Sinks.Async" ], "WriteTo": [ { "Name": "Async", "Args": { "configure": [ { "Name": "File", "Args": { "restrictedToMinimumLevel": "Information", "path": "%PROGRAMDATA%/logs/file.log", "rollingInterval": "Day", "formatter": "Serilog.Formatting.Compact.CompactJsonFormatter, Serilog.Formatting.Compact" } } ] } },

The above config is just a snippet from appsettings.json but it also includes other standard parameters set in it.

Please let me know if a windows service running as local system can write logs into %PROGRAMDATA% path configured through appsettings.json. The same log file works if it configured as part of the service in Program.cs

Log.Logger = new LoggerConfiguration() .MinimumLevel.Override("Microsoft", LogEventLevel.Information) .Enrich.FromLogContext() .Destructure.UsingAttributes() .WriteTo.Async(a => a.File(Environment.ExpandEnvironmentVariables("%PROGRAMDATA%\logs\file.log")) .WriteTo.Console() .CreateBootstrapLogger()

[bartelink]

There is an Async Sink, and that wraps a File Sink Each have their individual implementations and repos The File sink doesn't do anything magic - it just uses the .NET File APIs

As such, troubleshooting is the same as for normal file writes, i.e.

• stackoverflow can help
• SysInternals FileMon and/or related things can attach to monitor file writes

I suggest putting a (well formatted) version of this question on stack overflow (you can post a link here when you're done)

Github issues should be kept for are for bugs with repros

[seheri]

I have reached out here after I tried multiple combinations of queries for this issue on stackoverflow which did not help apparently. I hope to get some information about the issue which I am facing since quite sometime, please be considerate here.

[bartelink]

I'm not offended by your posting the question, not trying to imply a slapdown by closing the issue; let me add some context:

My last hour or two had one goal: Trim the Map and File Sink issue lists to things that the maintainers and/or others can ultimately resolve by writing documentation or implementation PRs

The value of being cruel to be kind is that hopefully people will be able to infer two key things:

• this is not and cannot be a Q&A forum for resolving all generic OS/.NET file access issues given the plethora of environments this is deployed in
• there is already an issue covering the most common desire that could conceivably be addressed wrt this sink: provide a more powerful/generic way to drive the file naming that the current policy

---

My actual answer to your problem can be summed up in one word though: sysinternal filemon or whatever it's called these days

Please include links to the relevant SO questions when reposting; the more info you can provide about what you've tried helps.

---

I appreciate your pain and frustration - I've been there. But this is not where the world can or should solve all file permission issues encountered when using this Sink. The Sink just uses System.IO, which talks to the OS. There is nothing magic about what the Sink does compared to any other .NET app that needs to write to a file in a given execution context.

The bottom line is that

• not everyone has knowledge of specific environments
• this repo implements the File sink, but does that on a neutral basis using the standard System.IO APIs
• there are very few people that watch this repo (and hence will ever see questions posted here). Of those, even fewer have the expertise and the time to assist with troubleshooting
• those that do have the time and expertise are far more likely to be on Stack Overflow, so posting there and tagging serilog will already get their attention.

Regardless, fixing any problem is going to rely on

1. a good problem description
2. maybe people looking at 1
3. troubleshooting by you and/or people helping
4. profit

If you feel that driving relevant eyes to a SO question is served by posting here, that's fine.

But, ultimately, it's not scalable to resolve all issues that people experience in the course of using this sink via Github issues; see https://www.nuget.org/packages/serilog.sinks.file