Ripshod
Part of the Furniture
I also saw that. My instance of syslog-ng wouldn't start because that file was overwritten (I use a remote syslog server). Just a couple of edits got it running again.syslog-ng.conf
Once you know you're fine.
I also saw that. My instance of syslog-ng wouldn't start because that file was overwritten (I use a remote syslog server). Just a couple of edits got it running again.syslog-ng.conf
I also saw that. My instance of syslog-ng wouldn't start because that file was overwritten (I use a remote syslog server). Just a couple of edits got it running again.
Once you know you're fine.
I didn't look at the timestamp before, but the file is called "syslog-ng.conf-2024-08-10T18:54:53", so it's not even of today...and a time-stamped file
I do indeed have a regular file and a time-stamped file, but the regular file contains my customization (adding an external log server with a specific hostname, which is definitely not part of the default Scribe configuration) ...
All that got changed was log_fifo_size in my existing syslog-ng.conf.
If you had previously downloaded and installed the v3.2.9 BETA development version, you would likely have the newest version of the "/opt/etc/syslog-ng.conf" file, so when updating to the latest v3.2.9 production release, the code would see no need to make a date/time-stamped backup. If the only differences were the values for the "log_fifo_size(NNN)" and/or "log_msg_size(NNN)" options, the code would simply update those values without making a backup.Are there conditions where the update to 3.2.9 will not backup syslog-ng.conf and replace it with a new version?
I'd highly recommend executing the following command just to double-check and make sure you have the very latest versions of all files before you start making any custom changes:Ya, I was kinda happy to see the conf file wasn't changed much. It is way past due for me to move my changes to syslog-ng.d anyway.
I also would have to sort out my syslog server changes as well as template and rewrite rules I made to push log entries to loki.
/jffs/scripts/scribe forceupdate
The latest version of the configuration file has a "2026-Feb-01" date stamp at the top of its header, and the critical changes are in the "source src" statement (see the "wildcard_file(...);" entry).
I downloaded the 3.2.9 configuration file from GitHub and compared it with the one of my router; it's very clear that the regular update did not touch/update my syslog.conf at all... (for example the date that you mentioned is missing)I'd highly recommend executing the following command just to double-check and make sure you have the very latest versions of all files before you start making any custom changes:
Bash:/jffs/scripts/scribe forceupdate
I haven't run the BETA and am definitely missing the new source configuration.Could you both post the "/opt/etc/syslog-ng.conf" file that was installed with the latest v3.2.9 production release update?
The latest version of the configuration file has a "2026-Feb-01" date stamp at the top of its header, and the critical changes are in the "source src" statement (see the "wildcard_file(...);" entry).
If you had previously downloaded and installed the v3.2.9 BETA development version, you would likely have the newest version of the "/opt/etc/syslog-ng.conf" file, so when updating to the latest v3.2.9 production release, the code would see no need to make a date/time-stamped backup. If the only differences were the values for the "log_fifo_size(NNN)" and/or "log_msg_size(NNN)" options, the code would simply update those values without making a backup.
Any other changes to the file contents would trigger the code to make a date/time-stamped backup before replacing the file. That is, if you run the latest script with a "forceupdate" parameter.
I'd highly recommend executing the following command just to double-check and make sure you have the very latest versions of all files before you start making any custom changes:
Bash:/jffs/scripts/scribe forceupdate
HTH.
source src {
unix-dgram("/dev/log" so_rcvbuf(65536) flags(syslog-protocol));
file("/proc/kmsg" program_override("kernel") flags(kernel));
wildcard_file(base_dir("/opt/var/log")
filename_pattern("syslogd.ScribeInitReboot.LOG")
recursive(no) max-files(1) follow_freq(1)
log_iw_size(1200) log_fetch_limit(1000) flags(syslog-protocol));
internal();
# uncomment the line below to pass ALL network log messages through syslog-ng filters #
#OFF# udp(port(514) flags(syslog-protocol));
};
I then ran the forced upgrade and that one did indeed update the configuration file and warn me about it.
...
PS: I never ran the 3.2.9 beta
I haven't run the BETA and am definitely missing the new source configuration.
/jffs/scripts/scribe stable
/jffs/scripts/scribe forceupdate
monitor-method(inotify), and very much to my surprise it worked (or: at least it loaded without complaint). I thought this was something introduced around 4.9, but this means reboot.LOG is not read at all unless a change is telegraphed. I've commented out follow-freq() for the moment.Interesting. Did you try the native Loki() destination and template?@Martinski
Thank you for the clarity update.
I re-ran the update with the forceupdate option so all is squared away now.
Just for future reference for someone.
I placed my syslog server settings in /opt/etc/syslog-ng.d/loki-syslog-server.
This was working ok with the exception that some of the filters where no longer working.
After rummaging around with scribe cmdline ui and using the lc option to show the loaded configuration. I noticed that
the files are loaded in alphabetical order. A rename of loki-syslog-server to z-loki-syslog-server followed by a re-start of
syslog-ng had everything working correctly again.
No, I cobbled together the destination and template as well as a few rewrite rules necessary since someInteresting. Did you try the native Loki() destination and template?
destination d_MyLogFile { file("/opt/var/log/MyLogFile.log"); };
destination d_MyLogFile { file('/opt/var/log/MyLogFile.log'); };
ethernet filter configuration file to prevent it from capturing log entries intended for the Skynet/firewall log files./opt/etc/syslog-ng.conf) is overwritten during a version update./opt/etc/syslog-ng.conf) to filter out from the "messages" log file all log entries tagged with the 'debug' severity level./opt/var/log/debugMessages.log]. This allows users to review the debug messages if it's deemed necessary (e.g. for reporting or troubleshooting possible issues).ft. Update filters option. When prompted to update the filter files, type y and follow the prompts to accept the update of any filter config file you may have previously installed manually.ft. Update filters" option. When prompted to update the filter files, type 'y' and follow the prompts to accept the update of any filter config file you may have previously installed.@define rotate "logrotate(enable(yes),size(2048KB),rotations(5))" just to make it simpler`rotate` after file("/opt/var/log/messages"Apr 7 17:10:11 RT-AX88U syslog-ng[14208]: Maximum log file size reached, rotating log file ... ; filename='/opt/var/log/truenaspt.log'
Apr 7 17:10:11 RT-AX88U syslog-ng[14208]: Reopened log file after logrotate; filename='/opt/var/log/truenaspt.log'
Apr 7 17:10:19 RT-AX88U syslog-ng[14208]: Maximum log file size reached, rotating log file ... ; filename='/opt/var/log/truenasmain.log'
Apr 7 17:10:19 RT-AX88U syslog-ng[14208]: Reopened log file after logrotate; filename='/opt/var/log/truenasmain.log'
Question I believe is relevant here. I use Scribe along with several other amtm AddOns, including unbound (with Scribe integration enabled). I have noticed that when rebooting the router (in my case BE88U, though also occurred with an AX86U), unbound will sometimes appear to be non-functioning from a logging perspective and sometimes be perfectly fine; determined from the logs in the GUI or by entering unbound manager and pressing "l" to view live logging.
I also notice that if Scribe is restarted, the live logging stops at that time, which leads me to believe there is a non-recoverable dependence for unbound logging with Scribe and a race condition on router reboot. I suspect this is not only with me, though may not be visible to others as use of Unbound might not be very broad and, even if it is, enabling Scribe integration is done through use of unbound_manager advanced under Advanced Tools.
Normally this wouldn't be a concern as I manually update Scribe, and unbound is only updated with entware, at most twice a year. Now that amtm auto-updater came out, however, I was wondering if this is something Scribe would handle (reloading unbound config on update), something that unbound manager would need to add (unlikely due to lack of continued development), or custom scripting, if that's possible?
syslog-ng and logrotate so that all Unbound log entries are filtered and log files are rotated accordingly (based on some predefined rules).syslog-ng and logrotate performing their actions as dictated by the configuration directives. There's nothing in the Scribe/uiScribe code that would treat Unbound config files any differently from the rest.Some interesting new possibilities with syslog-ng 4.10-2:
I'm playing around with #1:
- Integrating logrotate into syslog-ng
- Using @version:current and eliminating all the version checking/rewriting
- Using inotify instead of poll for checking the wild-card source (I think this works now but auto may now work as a config option) to cut CPU time. EDIT: inotify works but auto doesn't.
Obviously there's a race depending on how you have logrotate set up. I'll let you know how it turns out.
- Add at the top of the .conf file a definition:
@define rotate "logrotate(enable(yes),size(2048KB),rotations(5))"just to make it simpler- lower down, in the messages destination definition, add (these are backticks)
`rotate`afterfile("/opt/var/log/messages"- And then, in each file destination definition in syslog-ng.d, do the same.
EDIT: Early evidence is that the syslog-ng logrotation is working: it saves the existing log file as .log.1 and starts a new log file. Unlike logrotate, I can't see that there is going to be a compressed version of a rotated file.Code:Apr 7 17:10:11 RT-AX88U syslog-ng[14208]: Maximum log file size reached, rotating log file ... ; filename='/opt/var/log/truenaspt.log' Apr 7 17:10:11 RT-AX88U syslog-ng[14208]: Reopened log file after logrotate; filename='/opt/var/log/truenaspt.log' Apr 7 17:10:19 RT-AX88U syslog-ng[14208]: Maximum log file size reached, rotating log file ... ; filename='/opt/var/log/truenasmain.log' Apr 7 17:10:19 RT-AX88U syslog-ng[14208]: Reopened log file after logrotate; filename='/opt/var/log/truenasmain.log'
syslog-ng 4.10 version from Entware, I think it would be prudent to wait things out, see if any issues or bugs are lurking behind this latest version, and let the dust settle a bit before taking the plunge and starting to take things apart.2026-04-10T00:00:04.667737-04:00 xt8-garage syslog-ng[7247]: syslog-ng shutting down; version='4.10.2'
2026-04-10T04:39:59.926267-04:00 xt8-garage syslog-ng[22319]: syslog-ng starting up; version='4.10.2'
Apr 11 10:50:01 xt8-garage logrotate: /opt/sbin/logrotate: /lib/libc.so.6: version `GLIBC_2.27' not found (required by /opt/sbin/logrotate)
Apr 11 10:50:01 xt8-garage logrotate: /opt/sbin/logrotate: /lib/libc.so.6: version `GLIBC_2.27' not found (required by /opt/lib/libpopt.so.0)
2026-04-11T11:02:31.127107-04:00 xt8-garage logrotate: logrotate state -- version 2
2026-04-11T11:02:31.127107-04:00 xt8-garage logrotate: "/opt/var/log/wlceventd.log" 2026-4-11-10:0:0
2026-04-11T11:02:31.127107-04:00 xt8-garage logrotate: "/opt/var/log/messages" 2026-4-11-10:0:0
2026-04-11T11:02:31.127107-04:00 xt8-garage logrotate: "/opt/var/log/logrotate.log" 2026-4-11-10:0:0
2026-04-11T11:02:31.127107-04:00 xt8-garage logrotate: "/opt/var/log/firewall.log" 2026-4-11-10:0:0
2026-04-11T11:02:31.127107-04:00 xt8-garage logrotate: "/opt/var/log/syslog-ng.log" 2026-4-11-10:0:0
2026-04-11T11:02:31.127107-04:00 xt8-garage logrotate: "/opt/var/log/hostapd.log" 2026-4-11-11:0:0
We use essential cookies to make this site work, and optional cookies to enhance your experience.