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

Allow Log File to be Deleted at Runtime #96

Open
rustbomber opened this issue Apr 17, 2019 · 5 comments
Open

Allow Log File to be Deleted at Runtime #96

rustbomber opened this issue Apr 17, 2019 · 5 comments

Comments

@rustbomber
Copy link

rustbomber commented Apr 17, 2019

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 nblumhardt changed the title can not delete log file at runtime? Allow Log File to be Deleted at Runtime Apr 20, 2019
@nblumhardt
Copy link
Member

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
Copy link

+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
Copy link

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
Copy link
Member

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
Copy link

BTPDarren commented Jul 2, 2024

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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants