Scribe Scribe v3.2.8 [2026-Jan-26] - Entware syslog-ng and logrotate installer for Asuswrt-Merlin

[elorimer]

Updating the version of scribe does not necessarily change the version of syslog-ng — they are independently maintained baselines by different developers.

Perhaps I wasn't clear. Syslog-ng is at version 4.10; the entware version of it is at 4.7. The @version switch in syslog-ng controls what level features are enabled. If you set the @version to 3.5, features introduced in later versions would not be enabled. But, if the installed version is newer than the @version switch, syslog-ng throws an alert when it starts. To stifle the alert, @cmkelley stuck in some code that updated the @version switch to whatever the installed version of syslog-ng is.

The scribe code now doesn't test what level of syslog-ng is installed, it tests whether the fifo size/message size parameters have been updated (I think), which I think is just a scribe thing (and a good change), and if so (unnecessarily, confusingly) changes the @version switch from 4.7 to 4.7. There isn't any need to change the scribe version.

I don't quite agree with @cmkelley's solution, as I think it should be an option along the lines of updating the filters.

But yes, I get that syslog-ng is one project for the linuxsphere, and scribe is handled for our routers, brilliantly, by another developer.

 

[Stephen Harrington]

@Martinski just checking if the behaviour I'm seeing is "correct" or if I've got some other problem going on ...

I updated from an earlier development version, that is 3.2.7_26010522, straight to production version 3.2.8 with "scribe stable" and then "scribe forceupdate".
I've also got uiScribe installed with some custom filters.

Upon reboot now, I don't see log entries populating the uiScribe "buckets" until much later, I assume that is the 150 second delay you've added before scribe kicks in, is that correct?

But it is usually these initial startup log entries that I want to see, particularly for addons such as AdGuardHome and wan-failover for example ...
Are they lost? Is this the intended behaviour? If so I think I much preferred it the way it was, with all due respect
Or is my install borked in some way?

If not ...
I never really noticed the loss of the initial entries, but now I really DO notice the lack of the entries at the end of the bootup process in each category in uiScribe, as this was often what I was looking at to troubleshoot, if that makes sense.

Any chance of making this delay user-configurable or ability to turn it off, or return to the older behaviour?

And is it correct that I can now delete the entries in /opt/etc/logrotate.d except for the ones that the installer puts there?

Bit confused (as usual), any clarity appreciated!

At the moment I've "rolled back" via backupmon to my earlier "known good" setup with development 3.2.7_26010522.

Thanks again for all the work you are doing to improve the addons, it IS much appreciated!

 

[elorimer]

The messages shouldn't be gone. In fact, with the new behaviour script messages that were being lost might now not be lost. They might end up in messages though. The startup sequence has all the startup messages going to syslog, and when those thousand messages or so simmer down, they are appended to messages, syslogd and klogd stop, syslog-ng starts, and then the sorting into buckets starts.

I might go back and play with something I'd been doing before, which was for the startup part of syslog to be written out to a file, and then read back in by syslog-ng as a source. It needed a timestamp template and flow control, if I recall correctly. That gave me the full startup sequence, in timestamp order and sorted into buckets. It wouldn't work with the older behaviour, because of the delay, but I think will work better with the new behaviour.

I don't have a need for special logrotate configs, so I've deleted everything but A00 in logrotate.d [EDIT: Oops, A01]

EDIT: This is what I'm fooling with:

1. In rc.func.syslog-ng, change line 140 to read

  $catCmd "${syslog_loc}-1" > "/opt/var/log/startup.log"

2. Change line 142 to read

        [ -s "$syslog_loc" ] && $catCmd "$syslog_loc" >> "/opt/var/log/startup.log"

3. Those are sloppy for the moment.
4. Create a new configuration file in syslog-ng.d called "startup":

source s_startup {
file(
"/opt/var/log/startup.log" keep-timestamp(no)
);
};

5. In syslog-ng.conf, add a new source at the bottom log statement to read:

    source(src);
    source(net); # uncomment this and "source net" function above to get tcp log messages from local network
    source(s_startup); # uncomment this to read in messages from startup file

6. If instead you want to filter the startup into buckets, add that source(s_startup) to each separate configuration file instead.

I think on a reboot that will produce a messages file that will append with a timestamp at the 150 second mark, with all the logged messages from the restart in order, like so:

an 28 18:50:35 RT-AX88U avahi-daemon[13518]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.1.1.
Jan 28 18:50:35 RT-AX88U avahi-daemon[13518]: avahi-daemon 0.8 exiting.
Jan 28 18:50:35 RT-AX88U haveged: haveged: Stopping due to signal 15
Jan 28 18:54:00 syslogd started: BusyBox v1.25.1
Jan 28 18:54:00 RT-AX88U kernel: klogd started: BusyBox v1.25.1 (2025-12-26 12:24:37 EST)
Jan 28 18:54:00 RT-AX88U kernel: Booting Linux on physical CPU 0x0
Jan 28 18:54:00 RT-AX88U kernel: Linux version 4.1.51 (merlin@ubuntu-dev) (gcc version 5.5.0 (Buildroot 2017.11.1) ) #2 SMP PREEMPT Fri Dec 26 12:26:28 EST 2025
Jan 28 18:54:00 RT-AX88U kernel: CPU: AArch64 Processor [420f1000] revision 0
Jan 28 18:54:00 RT-AX88U kernel: Detected VIPT I-cache on CPU0

 

[Martinski]

Couldn't find the update option in the TUI... Turns out it's not available if scribe/syslogng is not running?

Is that intentional?

I don't understand what you're trying to say. If you can provide clear and readable screenshots to show what you're seeing, along with a clear description and relevant context, I can answer your question.

 

[Martinski]

This is the smallest of nits. When I updated from 3.2.6 to 3.2.8, the scribe version check updated syslog-ng.conf from 4.7 to 4.7. Which led me to look, since we have been at 4.7 for a long time.

I'm not quite following the version test. Instead of the first line of output from syslog-ng -V it seems to be testing the fifo size and message size parameters. That seems sort of self-referential.

IMO, it's the currently displayed UI messages that are inaccurate and can lead to some confusion because the syslog-ng configuration "version check" does a lot more than just checking the syslog-ng "@version" number. I'll take a look and modify the UI messages to be clear about the intended meaning/behavior.

Perhaps I wasn't clear. Syslog-ng is at version 4.10; the entware version of it is at 4.7. The @version switch in syslog-ng controls what level features are enabled. If you set the @version to 3.5, features introduced in later versions would not be enabled. But, if the installed version is newer than the @version switch, syslog-ng throws an alert when it starts. To stifle the alert, @cmkelley stuck in some code that updated the @version switch to whatever the installed version of syslog-ng is.

Yep, that's all correct.

The scribe code now doesn't test what level of syslog-ng is installed, it tests whether the fifo size/message size parameters have been updated (I think),

Nope, that's incorrect. The configuration "version check" is, in fact, still checking the syslog-ng version that's currently installed and updates Scribe's custom file "@version" number as needed, but it's also checking more than that. You can easily verify this: manually change the "@version" number (i.e. 4.7) in the "/opt/etc/syslog-ng.conf" file to be some other number; then run the CLI "Show scribe status" menu option, and you'll see the results. The issue, as mentioned above, is that the UI messages are currently inaccurate and therefore confusing.

 

[Martinski]

Upon reboot now, I don't see log entries populating the uiScribe "buckets" until much later, I assume that is the 150 second delay you've added before scribe kicks in, is that correct?

Yes, that's correct. On the uiScribe WebUI page, it can take up to ~3 minutes to fully update the individual log files if you log into the router immediately after a reboot.

But it is usually these initial startup log entries that I want to see, particularly for addons such as AdGuardHome and wan-failover for example ...
Are they lost? Is this the intended behaviour? If so I think I much preferred it the way it was, with all due respect
Or is my install borked in some way?

The log entries are not lost. What's happening is that the initial reboot log messages (i.e. about ~3 minutes worth of the bootup process) are getting saved directly into the "/opt/var/log/messages" file and are not filtered into the designated "buckets" of log files. I've been working on the next phase of the recent changes, where those initial reboot log entries will get filtered into their corresponding log files. The code is pretty much done; I just haven't had time to run testing and validation to double-check and fine-tune the solution.

And is it correct that I can now delete the entries in /opt/etc/logrotate.d except for the ones that the installer puts there?

Yes, you can delete the files in the /opt/etc/logrotate.d directory except for the 5 installed by Scribe (on a fresh installation). Technically, you really need only the "A01global" and "messages" configuration files, but the other config files that are installed by default have different settings from the global defaults, so they serve a valid purpose; but if you want only the global defaults to take effect, keep only "A01global" and "messages" configuration files.

 

[Martinski]

The messages shouldn't be gone. In fact, with the new behaviour script messages that were being lost might now not be lost. They might end up in messages though. The startup sequence has all the startup messages going to syslog, and when those thousand messages or so simmer down, they are appended to messages, syslogd and klogd stop, syslog-ng starts, and then the sorting into buckets starts.

Correct.

I don't have a need for special logrotate configs, so I've deleted everything but A00 in logrotate.d

You do need the "A01global" logrotate configuration file as the bare minimum.

I might go back and play with something I'd been doing before, which was for the startup part of syslog to be written out to a file, and then read back in by syslog-ng as a source. It needed a timestamp template and flow control, if I recall correctly. That gave me the full startup sequence, in timestamp order and sorted into buckets. It wouldn't work with the older behaviour, because of the delay, but I think will work better with the new behaviour.

As mentioned in my previous post, I've been working on a solution to get the initial reboot log entries saved into their corresponding filtered log files as opposed to just storing them all into the messages log file, but I simply have not had the time to test & validate so I can then issue a Beta version (hopefully, this coming weekend).

The latest code is currently only in my local GitHub development branch. If you're willing to give it a try and just "kick the tires" in its current "Alpha" state, I can get the code into the AMTM-OSR GitHub development branch on Thursday evening. Just let me know.

 

[elorimer]

I'll be interested in trying your approach, but no need to rush. I fooled with different approaches for a while years ago: was it better to have messages be a clean log from the reboot, saving the pre-reboot sequence somewhere else (if the reboot was a problem), or was it better to preserve the pre-reboot messages in the message log; was it better to keep the reboot messages in messages and also sort them into their buckets (i.e., not use the flags(final) for the reboot). But that was all mooted until your fix on the switchover behavior.

The question I had about @cmkelley's approach to the @version message was the automatic enabling of new features as a way of squelching the info message, instead of holding the version and making it an option to enable new features. At one point both the udp() and tcp() sources were deprecated, replaced by network(), but they never did get removed (although I can't get udp() to work, so scribe's current syslog-ng.conf won't work for me). SImilarly file() is now recommended to be replaced by wildcard-file(). Most of syslog-ng's development seems to be in areas not relevant to us, so I don't know how much unnecessary code might be loaded (even supposing @version controls that, as opposed to @include).

 

[Stephen Harrington]

I've been working on the next phase of the recent changes, where those initial reboot log entries will get filtered into their corresponding log files. The code is pretty much done; I just haven't had time to run testing and validation to double-check and fine-tune the solution.

@Martinski, thanks for your explanations and roadmap. Looking forward to testing the next phase of the code.

 

[Martinski]

The question I had about @cmkelley's approach to the @version message was the automatic enabling of new features as a way of squelching the info message, instead of holding the version and making it an option to enable new features.

Based on the syslog-ng documentation that I've been reading over the past few weeks (which, admittedly, is a small fraction of what's available online), Scribe is only scratching the surface of the quite extensive functionality and options currently available on syslog-ng 4.7 version, so I don't think it's worth worrying about whether newer features become "available" when updating the configuration "@version" number.

IMO, it's better for all users to have a common "@version" with a known and established set of features and functional behaviors that everyone is running with, as opposed to different users having different "versions" and features available, so when something doesn't quite work as expected or works only intermittently - is it because of a different configuration "@version" and feature set that results in some incompatible or inconsistent behavior?

It can easily become an intractable situation if issues come up due to different "@version" settings running "in the wild."

At one point both the udp() and tcp() sources were deprecated, replaced by network(), but they never did get removed (although I can't get udp() to work, so scribe's current syslog-ng.conf won't work for me).

Have you tried using the newer "network()" syntax instead of the "old way"?
For example:

source s_network { network(transport("udp") port(514)); };

It might be worth checking that out if you haven't already.

My 2 cents.

 

[Martinski]

Release Notes for Scribe v3.2.9_26013023 BETA Development Version
[2026-Jan-31]

1) IMPROVED: Modified code to be able to filter the initial log messages generated during the reboot process when syslog-ng has not yet been started.

2) IMPROVED: Modified code regarding the UI messages to make clear the intended actions taken if the syslog-ng configuration file is found "out of sync" when running a "status check."

Run the following commands to switch from the currently installed production release version to the latest BETA development branch version:

/jffs/scripts/scribe develop
/jffs/scripts/scribe forceupdate

Make sure to run *BOTH* commands. The first one executes the currently installed version of the script. The 2nd command then executes the newly installed BETA development version, which now runs the very latest code to configure the installation properly.

Sample screenshots:

The previous "version check" is now titled "options check" to make it clear that the code is checking more than just the version number:

 

[elorimer]

Have you tried using the newer "network()" syntax instead of the "old way"?

Playing around with this further, udp() is working. Go figure. I'll give network() a try later, following your lead on using the recommended functions.

In the meantime, you might think about changing the lines in syslog-ng.conf to

source net { udp(port(514) flags(syslog-protocol)); };

The deletion of the ip() part means syslog-ng will listen on all interfaces. That also would eliminate confusion about whether the ip specified should be the source or the router itself. The addition of the flag will eliminate double-time stamping for logs sent by syslog-ng clients, though it would be useful to have feedback on whether that would affect users who send AIMesh node logs to the main router. Here's an example of the change:

Jan 31 08:37:00 192.168.50.11 1 2026-01-31T08:37:00-05:00 truenasxeon dhclient 2771 - - No working leases in persistent database - sleeping.
Jan 31 08:38:31 truenasxeon dhclient[2736]: DHCPDISCOVER on eno1 to 255.255.255.255 port 67 interval 5

 

[XIII]

I don't understand what you're trying to say. If you can provide clear and readable screenshots to show what you're seeing, along with a clear description and relevant context, I can answer your question.

I was unable to find 'u' / 'Check for script updates' when syslog-ng was not running:

However, after starting syslog-ng I could update:

 

[XIII]

Unfortunately, after stopping syslog-ng to reproduce this "issue" for you I'm unable to start it again:

 

[XIII]

It looks like syslog-nd can't start because it has a Raspberry Pi as destination and rsyslog is failing to start there... (investigating)

 

[elorimer]

It looks like syslog-nd can't start because it has a Raspberry Pi as destination and rsyslog is failing to start there... (investigating)

That sounds unlikely to me. I think syslog-ng ignores things like that. But from a command line you can run syslog-ng -Fevdand it might point to what is the problem.

I had a similar error moving to the develop branch and I think running the forceupdate again fixed it...but I regret to say I don't recall exactly.

 

[Stephen Harrington]

@Martinski, have now given 3.2.9_26013023 development a pretty good thrash and it seems to be working as advertised in terms of the uiScribe "buckets" populating retrospectively after the scribe startup delay. I've culled all my (now) superfluous logtrotate.d files and done a couple of reboots.

Nice work and thank you!

I'm sure you had valid reasons for deciding on the 150 second delay, perhaps you can elucidate further why your investigations led you to that?
I can see the sleepSecsMIN=120, minSleepSecs=150 and sleepSecsMAX=210 constants and i can see you are waiting for 3 nvram variables to be "true", but maybe you can tell us why you picked those values and what the script is looking for before firing up?

Is it tunable at all for those of us that like to tinker further, or is that not advisable?

 

[Martinski]

I was unable to find 'u' / 'Check for script updates' when syslog-ng was not running:

Ah, OK. Yes, that's definitely intentional and the original behavior set by @cmkelley. When syslog-ng is not running, the main menu options are trimmed down to only what's considered essential or useful at that point.

 

[Martinski]

@Martinski, have now given 3.2.9_26013023 development a pretty good thrash and it seems to be working as advertised in terms of the uiScribe "buckets" populating retrospectively after the scribe startup delay. I've culled all my (now) superfluous logtrotate.d files and done a couple of reboots.

Nice work and thank you!

Thank you for testing and providing feedback. Glad the latest code is working well for you.

I'm sure you had valid reasons for deciding on the 150 second delay, perhaps you can elucidate further why your investigations led you to that?
I can see the sleepSecsMIN=120, minSleepSecs=150 and sleepSecsMAX=210 constants and i can see you are waiting for 3 nvram variables to be "true", but maybe you can tell us why you picked those values and what the script is looking for before firing up?

You can find the initial description of the 2 problems I was trying to address in post #141.

Essentially, during the reboot process, there is a deluge of log messages that get generated while all the kernel and built-in OS services are initialized & started up, along with other optional services the user may have selected (e.g. Samba, Media Server, FTP, Traffic Analyzer, AiProtection, etc.). This is followed by an unknown number of Entware services the user may have installed.

Based on testing/debugging I ran on 3 separate routers, plus reports from a debug version run by a friend of mine, this period during which a very high volume of syslog messages is generated may last anywhere between 100 and 180 seconds, depending on various factors.

Under those initial circumstances, the goal was to make the transition from using the built-in system loggers (klogd and syslogd) to starting syslog-ng as smoothly as possible and to minimize, as much as possible, the chances of log messages getting lost. Eventually, after some testing and fine-tuning, I arrived at what appears to be the "goldilocks zone" of 120-160 seconds, where the deluge of syslog messages has decreased enough so that the switch over to syslog-ng can happen smoothly.

The NVRAM variables are checked to make sure the system clock has synced, and all system services have been started.

The minimum of 120 seconds and the maximum of 210 seconds represent the range under which the debug tests were run to find the average "sweet spot" of 150 seconds that would (hopefully) apply to the largest number of router configurations.

Is it tunable at all for those of us that like to tinker further, or is that not advisable?

I suppose you could try to fine-tune the number of seconds used for the delay to fit your specific router model and current configuration, and at whatever point the switch over to syslog-ng no longer happens smoothly or starts losing more than a handful of log messages, you need to add a "cushion" of 15 to 20 seconds.

However, I would not recommend anything less than 120 seconds for the delay. Any value below that would be considered an unsupported setting/configuration, and I will not spend any time debugging or troubleshooting it.

HTH.

 

[XIII]

Ah, OK. Yes, that's definitely intentional and the original behavior set by @cmkelley. When syslog-ng is not running, the main menu options are trimmed down to only what's considered essential or useful at that point.

Why is updating Scribe considered useless when syslog-ng is not running? (Feels weird to me)