feat: Allow to show logs of all logging types by proxying messages

[susnux]

• Resolves [Bug] Logreader warns about log_type to be syslog #979

This creates an internal log file for all non file loggers, this enables showing all kind of logs.
The internal log file is then rotated by a background job, I think rotation makes more sense to keep the behavior similar to the file logger log file.
Maybe we can add a feature in the future to read also rotated logs (Nextcloud & internal log).

TODO

• Log rotation / truncating is required otherwise the log would grow infinitely.
• Adjust unit tests

[codecov]

Codecov Report

Attention: 39 lines in your changes are missing coverage. Please review.

Comparison is base (29d0240) 100.00% compared to head (ea032e8) 27.78%.

Additional details and impacted files

@@              Coverage Diff               @@
##              master    #1041       +/-   ##
==============================================
- Coverage     100.00%   27.78%   -72.22%     
- Complexity         0      188      +188     
==============================================
  Files             10       18        +8     
  Lines            168      565      +397     
  Branches          31        0       -31     
==============================================
- Hits             168      157       -11     
- Misses             0      408      +408     

Flag	Coverage Δ
unit	27.78% <42.64%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
lib/Controller/LogController.php	0.00% <ø> (ø)
lib/Log/LogProxy.php	100.00% <100.00%> (ø)
lib/Service/SettingsService.php	76.00% <ø> (ø)
lib/Listener/LogListener.php	43.75% <60.00%> (ø)
lib/BackgroundJobs/Rotate.php	0.00% <0.00%> (ø)
lib/Log/LogIteratorFactory.php	0.00% <0.00%> (ø)

... and 22 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the reviewing process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR reviewing process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

[kesselb]

I like the idea 👍

[come-nc]

@susnux Would it not be possible to access syslog logs without duplicating them?
Are there other backends than file and syslog?

[kesselb]

Are there other backends than file and syslog?

• Errorlog (using php's error_log)
• Systemdlog (requires https://github.com/systemd/php-systemd / https://github.com/uboslinux/ubos-php, both seem unmaintained now, and therefore we can consider deprecating it)

[susnux]

Would it not be possible to access syslog logs without duplicating them?

syslog in every case I know not allowed to be read by PHP, and I think this makes sense to not read other apps output.

Basically what this is doing is doing it similar as tee, so you have your native log for e.g. other logging solutions or journald integration, but also be able to have this in Nextcloud for quick analysis.

[come-nc]

Would it not be possible to access syslog logs without duplicating them?

syslog in every case I know not allowed to be read by PHP, and I think this makes sense to not read other apps output.

Basically what this is doing is doing it similar as tee, so you have your native log for e.g. other logging solutions or journald integration, but also be able to have this in Nextcloud for quick analysis.

But you are basically duplicating log, this is the same as supporting to have several log backend active at once, to have both files and syslog, no?