This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I am downloading the full logs from the ReadyNAS 214 dashboard. After that, I 'clear logs', which does remove all entries displayed on the dashboard. However, I noticed that many logs remain intact on the system if I ssh in and poke around, particularly the backup log files in /var/log/frontview/backup/. Various system logs also are not cleared.
This leads me to wonder what is the correct way of clearing out all logs then?
Well, you could clear things out more completely with journalctl. But maybe first use journalctl --disk-usage to see how much space you are actually talking about. My logs haven't been cleared for quite a while, and I am still only using 36 MB.
If you do want want to empty them more agressively, you'd use journalctl --rotate followed by journalctl --vacuum-time=1s. But personally I'd just leave well enough alone.
I am downloading the full logs from the ReadyNAS 214 dashboard. After that, I 'clear logs', which does remove all entries displayed on the dashboard. However, I noticed that many logs remain intact on the system if I ssh in and poke around, particularly the backup log files in /var/log/frontview/backup/. Various system logs also are not cleared.
Clear logs clears more than what is on the dashboard. Backup jobs are cleared using the control in the backup job setting (there is clear log on the logs page).
What system logs are you seeing? The NAS logs in the zip are mostly generated on the fly from journalctl, and don't exist as separate files.
Yes I can clear each backup log, one by one, from the backup jobs list. That's fine, thanks.
I notice the other system logs, e.g. smbd.log, contains data from a year ago, i.e. not 'cleared':
[2020/10/03 16:15:49.760477, 0] ../lib/util/become_daemon.c:136(daemon_ready)
daemon_ready: daemon 'smbd' finished starting up and ready to serve connections
There are several growing logs, which was an issue in the days past with older Duo/NV+ v2, etc (I recall), so just wondering how to manage these logs to avoid disks filling up with stuff no longer needed?
There are several growing logs, which was an issue in the days past with older Duo/NV+ v2, etc (I recall), so just wondering how to manage these logs to avoid disks filling up with stuff no longer needed?
My quick reply included an image - I thought the system hadn't registered the reply, so re-did it, but the second reply is also [currently] not showing. My guess is the image has caused it to go through a clearing/approval process.
My quick reply included an image - I thought the system hadn't registered the reply, so re-did it, but the second reply is also [currently] not showing. My guess is the image has caused it to go through a clearing/approval process.
The image does need to be approved (which I did), but it doesn't seem to be attached to a post.
The image shows that you are looking in the log zip file, and not with ssh. As I said before, most of the files (including that one) are constructed on-the-fly via journalctl.
Not sure why it doesn't clear out more, but as long as you have a good amount of free space in the OS partition (which you can see in volume.log), you should be fine. The log is also automatically truncated by the system, so you normally don't need to clear them.
There was an rsyslog app that mirrored the logging. That unfortunately wasn't written properly, and did result a full OS partition. But I think that has been removed.
Multiple times now, my replies are not appearing. I did write a full test response, it said "success" but then it doesn't appear after I refresh the thread. I recall a similar problem in the past, so wonder what is going on - of course this may not become visible either!
Multiple times now, my replies are not appearing. I did write a full test response, it said "success" but then it doesn't appear after I refresh the thread. I recall a similar problem in the past, so wonder what is going on - of course this may not become visible either!
Four of your posts triggered the automatic spam filter.
Well, you could clear things out more completely with journalctl. But maybe first use journalctl --disk-usage to see how much space you are actually talking about. My logs haven't been cleared for quite a while, and I am still only using 36 MB.
If you do want want to empty them more agressively, you'd use journalctl --rotate followed by journalctl --vacuum-time=1s. But personally I'd just leave well enough alone.
!
