Thanks, i will try to investigate what could be causing this anomaly.
It would be very nice, thanks for your effort.
I actually noticed this in 2.1.0.2 Beta, but I assume it’s this that’s dumping a lot of stuff (e.g. each BackendEvent) into the Application event log without my having asked. Is that meant to happen? Volume of log entries from Duplicati is pretty large, but not as bad as when Server restart looped.
Feature/windows service improvements #5490
Fortunately Windows seems to have some mechanism that’s keeping the event log size in check.
Not sure what you are asking? I think having a service log information in the Windows Event log is the expected behavior, and not something that you should opt-in for?
If you think there are too many messages, there is --windows-eventlog-level=warning, but the problem with logs is that there are always too many, until you need them, and then there are too few. I would think that only logging warning messages by default would be too little for a default setting, but we could log at the information log level and see if some events should be moved to verbose.
--log-file-log-level (Enumeration): Log file information level
Specify the amount of log information to write into the file specified by the option --log-file.
* values: ExplicitOnly, Profiling, Verbose, Retry, Information, DryRun, Warning, Error
* default value: Warning
but it actually isn’t on at all unless --log-file is given, which raises the mentioned no-logs pain.
What’s on is the job log, highlighting Warning and Errors, plus lesser Messages in Complete log.
I’m not expert in “right” usage. Opinions on the web seem to vary. Some say it’s not just services, which is kind of what I’m pointing out. Windows Service is getting rather preferential treatment by this, maybe unlike any other way of running Duplicati. I’m thinking of backups that get warnings in thousands. Here, the job log truncation is somewhat handy in limiting size, but it does cut the info.
is my setting, and it might be the default. Basically, flooding by Duplicati has crowded others out.
Agree, which is why I’m looking for improving logging in general, not just a Windows service flood. Organizations reportedly may have event log retention requirements, which may add to their pain.
Having confirmed current behavior is intended, I guess we can see if it helps or it gets complaints.
True, if there is no file to log to, it does not matter what you set this to. Is that what you mean?
It is just “on by default” because it is running as a service, and the expectation is that no other output is possible. You can set --windows-eventlog and --windows-eventlog-level for the Server even if it is not running as a service. No expert either, but I do think that logging to the eventlog is the “right way” fro a service.
I can see that this is problematic. Maybe the right thing to do for now is to make the default log-level Warning here?
Yes. The first quoted line means that log file log level does not matter with no log file.
Second quoted line refers to job log in both its Complete log and user-friendly styles.
"MessagesActualLength": 0,
"WarningsActualLength": 0,
"ErrorsActualLength": 0,
"Messages": null,
"Warnings": null,
"Errors": null,
Other output is possible, however one has to ask:
C:\Duplicati\duplicati-2.1.0.101_canary_2024-12-06-win-x64-gui>Duplicati.Server.exe help | findstr log
--windows-eventlog: Use this option to log to the Windows event log.
--windows-eventlog-level: Use this option to set the log level for the Windows event log.
--log-file: Output log information to the file given
--log-level: Determine the amount of information written in the log file
This is saying there is no “right way” for anything other than Windows?
Ignoring that, there is also the Applications and Services Logs area.
I see two backup programs with logs there, not Application in Windows:
This is a matter of style, but making a big log in one’s own area seems more polite to others.
It also saves us from having to explain to someone how to filter events to get Duplicati ones.
It would avoid floods in all-is-well case. Warning floods are possible, as warnings aren’t fatal.
Logging has a long history of efforts. I see one issue called “Log Retention” which is actually complaining that logs in the database get lost when user recreates it. More subtle is rollback.
Another issue wants to log to syslog, and log4net comes up. There’s also server vs. job logs.
Lots of logging challenges.
Arh, I missed that suggestion detail: Do not log to “Applications”, but create a separate log just for Duplicati. Great suggestion! I have created an issue for logging to an individual location.
Yes, logging is deceptive as it looks so simple, but is actually a lot of work.