NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Correct way to delete all logs
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 o...
aks-2 wrote:
I am not so worried about free space, just want to avoid issues later - so this is just maintenance:
> df Filesystem 1K-blocks Used Available Use% Mounted on udev 10240 4 10236 1% /dev /dev/md0 3862208 629072 3007244 18% / tmpfs 1032992 12 1032980 1% /dev/shm tmpfs 1032992 664 1032328 1% /run tmpfs 516500 1656 514844 1% /run/lock tmpfs 1032992 0 1032992 0% /sys/fs/cgroup /dev/md125 8775854208 5654598068 3119758764 65% /data
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.
aks-2 wrote:
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?
aks-2 wrote:
I notice the other system logs, e.g. smbd.log, contains data from a year ago, i.e. not 'cleared':
There is no smbd.log file on my system.
Are you finding this with ssh? If so, was rsyslog installed on your system?
aks-2 wrote:
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?
How full is your OS partition?
I am downloading from the dashboard, and unzipping the file. I find 113 log files, here is a snip:
I am not yet worried about OS partition space, just establishing the correct process for clearing (maintenance).
# df Filesystem 1K-blocks Used Available Use% Mounted on udev 10240 4 10236 1% /dev /dev/md0 3862208 629072 3007244 18% / tmpfs 1032992 12 1032980 1% /dev/shm tmpfs 1032992 664 1032328 1% /run tmpfs 516500 1660 514840 1% /run/lock tmpfs 1032992 0 1032992 0% /sys/fs/cgroup /dev/md125 8775854208 5654598068 3119758764 65% /data
Looks like I don't have to worry for a while, but for maintenance would like to better understand.
Cheers
I am downloading the logs via the dashboard, then unzipping them. Here is an extract (it shows the file I mention) which has 113 log files:
I am not worried about free space, but here is volume info:
# df Filesystem 1K-blocks Used Available Use% Mounted on udev 10240 4 10236 1% /dev /dev/md0 3862208 629072 3007244 18% / tmpfs 1032992 12 1032980 1% /dev/shm tmpfs 1032992 664 1032328 1% /run tmpfs 516500 1660 514840 1% /run/lock tmpfs 1032992 0 1032992 0% /sys/fs/cgroup /dev/md125 8775854208 5654598068 3119758764 65% /data
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.
aks-2 wrote:
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
