[Bug] Logreader warns about log_type to be syslog #979
Description
Steps to reproduce
- configure 'log_type' to be 'syslog',
- wait for warning
Expected behaviour
This is one of the defined ways to log system messages, so everything should be fine
Actual behaviour
Visible message:
Information Logreader File-based logging must be enabled to access logs from the Web UI. Your log_typeis currently set to: [syslog]. If you feel this is an error, please verifylog_type in your config.php and check the Nextcloud Administration Manual. This is not an actual log entry.
Activity
joshtrichards commentedon Aug 22, 2023
Hi @Antreesy - What's your concern? It's not an error or even a warning. It's just informational. The alternative is to have nothing displayed.
Context: The
logreaderapp can't access NC logs if they're sent to the system syslog. When using syslog, your logging destination (and underlying storage) is driven by your syslog daemon configuration. Sometimes the logs won't even be retained on-server if centralized logging is in-use. Same goes forsystemdlogging.Antreesy commentedon Aug 22, 2023
Hi @joshtrichards , thanks for the quick reply. Got this from the customer ticket, who is claiming, that it was possible to use
syslogand still use alogreaderapp to observe them before Nc27. Did i misunderstood one of you, probably?joshtrichards commentedon Aug 22, 2023
No way that was possible that I can think of. Until recently (i.e. NC27) the logreader app hung when opened if syslog was configured. :) See #866.
joshtrichards commentedon Aug 22, 2023
Though now you've got me wondering if we previously permitted a config like this:
...and logged simultaneously to both channels (file+syslog) just because the
logfilewas configured. 🤔 If we did it was probably accidental.It is also possible that previously if there happened to be a
nextcloud.logon-disk (maybe an old one) that it would load that one even if syslog was configured. But if that was the case it just means "using logreader" under that scenario would have been to look at outdated logs, not current logs.Antreesy commentedon Aug 22, 2023
Thanks for providing a link, I have already forgot about it, and now it returns to me 🙈 🪃
Then I'll ask for configuration, to see if that was a reason.
Antreesy commentedon Aug 23, 2023
So, customer used
log_type: syslogall the time, but syslog was configured to write the messages to the file path wherelog_type: filewould store it, so, defaultnextcloud.logfile. Therefore the messages were shown up in Web-UI.Here an excerpt from rsyslog.conf
I guess, it should work then, as before, only if there weren't any changes, that block this comfiguration?
joshtrichards commentedon Aug 23, 2023
That really should have never worked, but here we are. Hah. Okay, at least now it makes sense.
Setting their
log_typetofilewould fix this, but they're replicating their logs off-machine via rsylog too (I think that's what the@fbhsyslogis doing). So presumably that's not an option.Hmm. I guess we could change the logic to something like:
...or something along those lines.
This would still accomplish the main goal of the original PR, but the side effect would be we'd still load misleading old log files for people that happen to have
logfileconfigured even though they're using syslog/systemd. And that could get confusing.We then also can't add a warning "may be old logs you're viewing" because that would impact people who are doing this intentionally... like this user.
Another possibility might be if rsyslog supports input from pipes or, perhaps, replication from a file-based log. 🤔 Then they'd do this on their own outside the scope of NC.
Bigger picture: Maybe adding a new
log_type(or making it an array permitting multiple simultaneous log_types) would be a cleaner approach. But we have to be careful - and that is outside the scope of thelogreaderbecause that gets into territory that entails changes in core. The logging has to be very reliable and lightweight to not create problems throughout NC.Just brainstorming. No commitments being made here. Others will have to weigh in.
susnux commentedon Nov 9, 2023
Maybe we can even support all logging types by no longer depend on nextcloud's log but listen to
OCP\Log\BeforeMessageLoggedEventand create our own one.MrRinkana commentedon Mar 28, 2025
I just realised I commented on a pull request so I'll write here aswell
It would really be awesome if multiple logging backends could be used simultaneously, for example with a config like this:
Which I think is a better way than #1041 (if I'm understanding it correctly)
Edit: If you want to be really fancy you could support different log levels for the different backends, but that would need different config syntax, and is not strictly necessary - maybe more fit as a part 2 enhancement. Would allow cases like "log level warn" nextcloud.log but "log level info" syslog (likely accompanied with a filter)