[About a number of logs...]

9 minutes ago, flyride said:

 

I believe you do not need to be concerned. The design of Linux in general is to manage log files in a way that does not exhaust the storage available.  Spurious data in logs does use up space, but I did not suggest there was a crash problem solely due to log utilization. Logging is a good thing; zeroing log files is an unnecessary and forensically destructive practice.

 

In DSM, syslog events are logged by default to /var/log/messages.  Each Linux installation has syslog rules that split off certain logs to other files.  There are also multiple ingress points.  Kernel events, for instance, are independently logged to the kernel log and the syslog default.

 

There are a number of unimpactful, essentially useless, and unmanageable error logs due to unsupported system events in XPEnology. My intention was solely to improve the signal to noise ratio in the log files (make them more useful) by suppressing those types of logs.

Thank you very much.

[About a number of logs...]

24 minutes ago, flyride said:

I suggest you read up on logrotate.  TL;DR the system won't run out of space for logs, it self-manages.

Thanks. I'll read logrotate.

Questions about other logs, including smart error
https://xpenology.com/forum/topic/29581-suppress-virtual-disk-smart-errors-from-varlogmessages/
If you use a filter, as indicated by this address, the /var/log/messages does not record its logs.
/var/log/messages
Is it recorded not only in this place but also elsewhere?
If it's only suppressed here, I agree with the following:
The result is spurious error messages logged to /var/log/messages every few seconds, wasting disk space and SSD lifecycle, and making it hard to see what's happening

As you say, if you are self-managing so that you don't run out of space, you don't have to periodically make the log file zero.
(To stabilize the system, we tried to make the log file zero periodically.)

/var/log/messages
Will suppressing the logs here help you troubleshoot the following problems?
"wasting disk space and SSD lifecycle, and making it hard to see what's happening."

I'm sorry I asked you so many times.
I'm worried that I'm going to lose data because of a small problem I don't know.

[About a number of logs...]

About a number of logs...
The system's hard disk is not infinite and is limited.
Among other things, the system partition is smaller. (i think it's approximately about 5gb.)
this post has made it aware that xpenology is generating a lot of logs.
https://xpenology.com/forum/topic/31530-how-to-suppress-the-log/
i didn't know xpenology was writing so many logs and i'm concerned about this.
If the log fulls up the system partition, having trouble logging in, unstable or not turning on?

[How to suppress the log?]

13 minutes ago, flyride said:

Actually now that I'm looking at it, you are trying to filter non-disk messages.  All the other filters presume and require that there is a /dev/sdx reference in the log entry.

 

You'll need to modify the file in this way:

filter fs_cachemonitor { match("cache_monitor\.c:.*Can't support DS with cpu number" value("MESSAGE")); };
filter fs_allmsgs { filter(fs_badsec) or filter(fs_errcnt) or filter(fs_tmpget) or filter(fs_health) or filter(fs_sdread) or filter(fs_stests) or filter(fs_tstget); };
filter fs_smart { filter(fs_disks) and filter(fs_allmsgs); };
filter f_smart { filter(fs_smart) or filter(fs_cachemonitor); };

log { source(src); filter(f_smart); };
 

That's amazing. It's really cool. This issue has been resolved. 

But like you said, why is this happening?

so is this a common problem?

 

[How to suppress the log?]

my system: ESXi 6.7 i5-6500 cpu / 1.03b(DS3615xs) / DSM6.2.3-25426 /

 

# tail -f / var / log / messages

 

The problem that occurs is "cache_monitor" code.

log:

2020-07-11T18:00:16+09:00 min synostoraged: SYSTEM:     Last message 'cache_monitor.c:1557' repeated 6 times, suppressed by syslog-ng on min
2020-07-11T18:00:16+09:00 min synostoraged: cache_monitor.c:1557 Can't support DS with cpu number (1)

This log repeats endlessly.

 

The way I tried was to add syntax.

 

Added to this syntax for convenience.

↓ ↓ ↓

 

# ESXiSmart.conf
# edit the [bracket values] with drive slots where SMART should be suppressed
# in this example /dev/sda through /dev/sdl are suppressed
# add cache_monitor.c:1557 Can't support DS with cpu number (1) drop

filter fs_disks { match("/sd[a-l]" value("MESSAGE")); };

filter fs_badsec { match("/exc_bad_sec_ct$" value("MESSAGE")); };
filter fs_errcnt { match("disk_monitor\.c:.*Failed\ to\ check" value("MESSAGE")); };
filter fs_tmpget { match("disk/disk_temperature_get\.c:" value("MESSAGE")); };
filter fs_health { match("disk/disk_current_health_get\.c:" value("MESSAGE")); };
filter fs_sdread { match("SmartDataRead.*read\ value\ /dev/.*fail$" value("MESSAGE")); };
filter fs_stests { match("SmartSelfTestExecutionStatusGet.*read\ value\ /dev/.*fail$" value("MESSAGE")); };
filter fs_tstget { match("smartctl/smartctl_test_status_get\.c:" value("MESSAGE")); };

filter fs_cachemonitor { match("cache_monitor\.c:" value("MESSAGE")); };
filter fs_cachemonitor2 { match("cache_monitor.*(1)$" value("MESSAGE")); };

filter fs_allmsgs { filter(fs_badsec) or filter(fs_errcnt) or filter(fs_tmpget) or filter(fs_health) or filter(fs_sdread) or filter(fs_stests) or filter(fs_tstget) or filter(fs_cachemonitor) or filter(fs_cachemonitor2); };
filter f_smart { filter(fs_disks) and filter(fs_allmsgs); };

log { source(src); filter(f_smart); };
 

But it doesn't work.
How can we suppress these logs?

 

>Referenced posts