Allow Log File to be Deleted at Runtime

[rustbomber]

I use sinks-file on windows system, when web app runing, log write to file, now I want to delete the log file at runtime, windows report:

File is in use
The operation could not be completed because the file was opened in dotnet.exe

I use shared parameter, set true, is not working.

my code :

const string template = "{Timestamp:yyyy-MM-dd HH:mm:ss.ffffff} {Level:u4} {SourceContext} {Message} {Exception}{NewLine}";
Log.Logger = new LoggerConfiguration()
    .ReadFrom.Configuration(config)
    .Enrich.FromLogContext()
    .MinimumLevel.Is(minimumLevel)
    .WriteTo.Console(outputTemplate: template)
    .WriteTo.Debug(outputTemplate: template)
    .WriteTo.File(path: Path.Combine(AppContext.BaseDirectory, "Logs", "log.txt"), outputTemplate: template,
        fileSizeLimitBytes: 5242880, rollingInterval: RollingInterval.Day, rollOnFileSizeLimit: true, retainedFileCountLimit: 31, shared:true, buffered: false).CreateLogger();

[nblumhardt]

Hi - shared: true sets the file to allow read-write sharing; deleting the file is not supported in this mode.

It seems like there are possibly two separate requirements here:

1. Allow the file to be deleted
2. Recreate the file when this happens

I think we could allow (1) without initially worrying about (2) - this might be handy, for instance, in the situation where unbounded log file growth occurs and the file needs to be removed before the process can be (safely?) stopped.

I'm not sure how widely valued this scenario is, though - any thoughts?

[lscorcia]

+1 for this issue and the related #128 . I have migrated a large solution from log4net to Serilog only to discover this issue when moving to production. Back to log4net until this gets resolved.

[dgxhubbard]

This is definitely an issue I wanted to switch to serilog but found this issue. When the app is allowing the log file to be deleted means there is less to sift through to find a problem. We do this all the time and it saves time finding issues. Why are you locking the log file?

[nblumhardt]

Thanks for the nudge!

Nothing's happened here because between my:

I'm not sure how widely valued this scenario is, though - any thoughts?

and any response was four years, which somewhat slowed thing down :-)

I think the next step would be for someone to investigate the impact of making this change (part 1, or parts 1 & 2) and can share some info on what would be required, and which other parts of the code might break (especially around rolling, perhaps?).

If the change is small and the impact low and well-understood, I don't think anyone has been opposed to supporting this - it's just a prioritization issue currently.

HTH!

[BTPDarren]

I have just found this to replace Log4Net due to versioning issues.

My use case is that I have a windows service that is performing a data sync and logging is required to be able to monitor it.

I have the service and a monitoring app that will reload the log files found in a specific location.
I often remove logs while an app or service is running, in fact its common. with log4net I am pretty sure it would re-create the file if its deleted.

I have also found while replacing log4net, the FileSystemWatcher fails to fire events on the log files in the folder because they are locked.

My work around for now (I really don't want to roll back to log4net)

Instead of creating the logger at the app start, I have a method I call to setup the logger and write out the information then re-setup

        private static void LogInfo(string message)
        {
            logger = new LoggerConfiguration()
                   .ReadFrom.AppSettings()
                 .Enrich.WithThreadId()
                 .CreateLogger();

            logger.Information(message);
            logger.Dispose();

            logger = new LoggerConfiguration()
                   .ReadFrom.AppSettings()
                 .Enrich.WithThreadId()
                 .CreateLogger();
        }

While this is not ideal , it solves the problem in that the watcher detects changes and you can delete the file as you want and it will get re-created next time its needed

Shared = true did not work with the watcher either

My app settings if your interested

	<appSettings>
		<add key="serilog:using:File" value="Serilog.Sinks.File" />		
		<add key="serilog:write-to:File.path" value="%APPDATA%\SEPWorkerService\Log\applog.log" />
		<add key="serilog:minimum-level" value="Information" />
		<add key="serilog:write-to:File.rollingInterval" value="Day" />
		<add key="serilog:write-to:File.rollOnFileSizeLimit" value="true" />
		<add key="serilog:write-to:File.shared" value="true" />		
	</appSettings>

[JakubTracz]

+1 to this issue - I have a scenario in my desktop app where I need a new logger each time a "robot" is launched. Once it's done, I display the executions historical data to the users and they can decide whether to keep the log files and other data pertinent to the specific robot run. The issue is they cannot remove the last entry without restarting the app as it's locked.

[nblumhardt]

@JakubTracz disposing the per-robot logger before attempting to delete the file should sort this out.

[JakubTracz]

@nblumhardt I'm not sure how to achieve it with DI. This is my setup:

I use Map to create 2 loggers: 1/app run & 1 per each robot run

When running the robot I'm creating a scope by adding the robot key property so it's mapped correctly and creates a robot-run-specific file:

Inside Robot.Run, there a lot of different injected services, all of them using an ILogger from the DI and writing logs to a separate log file.

I'm not sure how to dispose of only the logger for this scope, if you know exact steps, it would be much appreciated :)

[nblumhardt]

It's a bit roundabout, but setting sinkMapCountLimit to 1:

https://github.com/serilog/serilog-sinks-map?tab=readme-ov-file#limiting-the-number-of-open-sinks

and logging at least one non-robot-specific event after each run would do the job.