Many users of Mikrotik’s RouterOS and The Dude monitoring system have encountered an issue where the syslog server seemingly stops creating new log files after a certain period, or when the initial log file reaches a significant size. This can be particularly frustrating when relying on syslog for network monitoring and security analysis. Instead of rotating hourly as configured, the system continues to append logs to the first file created, leading to a single, massive log file that eventually halts new log entries.
One observed symptom is that after a reboot, The Dude correctly initiates a new log file. However, this file naming convention appears to be delayed by one hour. For instance, a reboot at 16:20 might result in a log file named “Syslog-2010.11.09-15.20.log”. This discrepancy suggests a potential time synchronization issue within the Mikrotik environment, even though the actual log entries within the Syslog view reflect the correct timestamps.
Users have investigated time settings within RouterOS, including the system clock, time zone configurations, and NTP client synchronization. Configurations often reveal the time zone correctly set to local time, and NTP synchronization confirmed against external time servers. However, discrepancies between the BIOS time (potentially defaulting to GMT) and the RouterOS time zone settings might contribute to this logging anomaly. Attempts to manually adjust the BIOS time often prove ineffective as RouterOS tends to override it upon booting, reverting it back to GMT.
This behavior is not only perplexing but also impacts log management efficiency. When the syslog file grows excessively large, approaching 100MB in some reported cases, it ceases to record new logs altogether. A temporary workaround involves rebooting the server, which forces The Dude to generate a new log file and resume logging. However, this is far from a sustainable solution for continuous and reliable network monitoring.
If you are experiencing similar issues with your Mikrotik syslog server failing to rotate logs and seemingly stopping to send log files after some time, community feedback and suggestions for a permanent fix are highly valuable. Sharing your experiences and potential solutions can help in identifying the root cause and establishing a robust logging mechanism for Mikrotik environments.
