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

[Martinski]

On Saturday evening, I started to take a much closer look at the 2 major junctions when a router running Scribe transitions from using the built-in system loggers (klogd and syslogd) to running syslog-ng (when Entware services are started after the USB-attached drive is mounted), and vice versa (when Entware services are stopped after the USB-attached drive is unmounted).

After analyzing the sequence of events around the execution flow of the '/jffs/scripts/post-mount' and '/jffs/scripts/unmount' scripts, and also running some debugging code, I found 2 significant problems:

1) When the call to Scribe found in the '/jffs/scripts/unmount' script is made *after* the Entware services are stopped, it fails to properly reset and put back the system log files so the built-in system loggers can then proceed to update them. This, in turn, is causing hundreds of log messages to be "lost" during a reboot sequence.

2) Upon a system reboot, when Entware services are started, syslog-ng was shutting down the built-in system loggers too early and with a minimum 2-second delay (and perhaps more in some cases), causing hundreds (and possibly close to a thousand) of reboot log messages to be "lost" due to the "deluge" of log entries flooding the system logs within the first ~2 to ~3 minutes of the bootup process (the time can vary depending on the number of built-in services and Entware services being started, and other system initialization activities).

So in order to address the above 2 problems, I've modified the code. For the 1st issue, when unmounting the USB drive, I'm making sure that the system log files are put back after syslog-ng is stopped, and before the built-in loggers (klogd and syslogd) are restarted. Also, I've added code to save a backup of the syslog-ng messages log file, for restoration purposes.

For the 2nd problem, I'm creating a background script to handle the delay of starting syslog-ng service until the reboot sequence has completed, and system activity has reached a more "normal" state, when the deluge of reboot log messages has also subsided. This usually happens within the first ~3 minutes after a reboot, and only then will the background task start syslog-ng in a more "stable" context/environment.

I plan to have a new BETA version of Scribe by Sunday evening once I've completed, tested, and validated (as much as I can) all the recent changes.

Just FYI.

 

[Twiglets]

Typical ... I actually do 'something' with scribe and you 'change' it !!! <jk>

Thanks for the detective work to make things better ... much appreciated.

Look forward to the 'improved' version that is thankfully without 'AI' [Cough Spit], long may it continue !!!

[Must be one of the few things that don't include the 'AI' [Cough Spit] word ... expect 'Soap powder/pods' to have 'AI' included soon !!!]

 

[elorimer]

For the 2nd problem, I'm creating a background script to handle the delay of starting syslog-ng service until the reboot sequence has completed, and system activity has reached a more "normal" state, when the deluge of reboot log messages has also subsided. This usually happens within the first ~3 minutes after a reboot, and only then will the background task start syslog-ng in a more "stable" context/environment.

Awesome work. This is likely a more robust solution than my idea of simply making syslog-ng start with S99. There's no reason syslog-ng has to be first out of the block.

 

[aru]

How to add another logs to the uiscribe?

I only need to create configuration files containing the keywords I want to filter in the /opt/etc/logrotate.d and /opt/etc/syslog-ng.d directories. The Scribe plugin will then automatically load them into the Web UI for easier viewing and management. If I want to disable the filtering later, I can simply delete the custom configuration files.

I use acsd as an example by copying the existing wlceventd configuration file and modifying its contents to filter acsd-related messages.

/opt/etc/syslog-ng.d/acsd

destination d_acsd {
    file("/opt/var/log/acsd.log");
};

filter f_acsd {
    program("acsd") or message("acsd") or program("cfg_server") or
    message("cfg_server") or
    message("DFS")
;
};

log {
    source(src);
    filter(f_acsd);
    destination(d_acsd);
    flags(final);
};

/opt/etc/logrotate.d/acsd

/opt/var/log/acsd.log {
    rotate 4
    postrotate
        /usr/bin/killall -HUP syslog-ng
    endscript
}

After creating the acsd configuration file, go to the Scribe menu in amtm and run rl, lr, and rs to reload the configuration and restart syslog-ng. Once completed, log in to the router and you will see an additional set of acsd-related information.

In addition, I referred to another article to forward all information from the node hosts back to the main router, making it easier to view everything in one place and enabling centralized aggregation of node host logs.

Scribe - Feature to support AiMesh node(s) log?

I went in the other direction. Got scribe on router and both nodes. Have nodes forwarding to router (A00remote). Syslog-ng filters putting all of it where it suppossed to go. Debating creating my own filters based on the hostname of the AImiesh nodes (logrotate as well), the part two. This...

www.snbforums.com

I hope the above explanation is helpful to you.

 

[Martinski]

Release Notes for Scribe v3.2.7 BETA Development Version
[BETA v3.2.7_26011122] [2026-Jan-12]

1) FIXED: When the call to Scribe found in the '/jffs/scripts/unmount' script was made *after* the Entware services had been stopped, it failed to properly reset and put back the system log files so the built-in system loggers could then proceed to update them. This, in turn, was causing hundreds of log messages to be "lost" during a reboot sequence.

2) FIXED: Upon a system reboot, when Entware services are started, syslog-ng was shutting down the built-in system loggers too early and with a minimum 2-second delay (and perhaps more in some cases), causing hundreds (and possibly close to a thousand) of reboot log messages to be "lost" due to the "deluge" of log entries flooding the system logs within the first ~2 to ~3 minutes of the bootup process. Now, the start of syslog-ng is delayed for 150 seconds after "rc.unslung" is called to start all Entware services.

3) IMPROVED: Added 2-hour, 3-hour, and 4-hour intervals for the logrotate cron job options.

4) IMPROVED: Decreased the log message size to 2048 (from original 16384) in the syslog-ng configuration file.

5) IMPROVED: Increased the log FIFO queue for the number of messages to 1024 (2048 if total RAM > 512MB) in the syslog-ng configuration file.

6) IMPROVED: Improvements in the display of CLI menu options.

7) Miscellaneous code improvements.

To update from the currently installed production version to the latest 3.2.7 BETA development version, run the following commands on an SSH terminal session:

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

Sample screenshots:

Below is a sample screenshot showing the message generated when the Scribe CLI menu is launched while waiting for the syslog-ng service to be started following a reboot. The wait may be up to 150 seconds if you log into an SSH terminal immediately after the router has rebooted, but before syslog-ng is started by the background process. Simply wait for the number of seconds shown in the message.

 

[Martinski]

...
/opt/etc/logrotate.d/acsd

/opt/var/log/acsd.log {
    rotate 4
    postrotate
        /usr/bin/killall -HUP syslog-ng
    endscript
}

Just an observation: starting with Scribe v3.2.6 production release, it's no longer necessary to create a logrotate configuration file for each filtered logfile unless you want to override the global defaults set in the "/opt/etc/logrotate.d/A01global" file. And if you do create a configuration file, it's highly recommended to omit the "postrotate/endscript" option since that's already set by the global defaults.

 

[aru]

Just an observation: starting with Scribe v3.2.6 production release, it's no longer necessary to create a logrotate configuration file for each filtered logfile unless you want to override the global defaults set in the "/opt/etc/logrotate.d/A01global" file. And if you do create a configuration file, it's highly recommended to omit the "postrotate/endscript" option since that's already set by the global defaults.

It seems that starting from Scribe v3.2.6, /opt/etc/logrotate.d/A01global uses a centralized management approach. Unless there is a need to override the default behavior, there is no need to create additional logrotate configuration files. Thanks to the developer for the clear explanation and guidance.

 

[elorimer]

the global defaults set in the "/opt/etc/logrotate.d/A01global" file

Along these lines, we can get rid of A00global.

Giving it a go now.

Also, when Entware updates syslog-ng to 4.10, we'll be able to get rid of logrotate altogether, including the sighup

 

[Twiglets]

Installed and up and running !!!

WWIII *has* NOT Started !!!

All is Well !!!

 

[Martinski]

Along these lines, we can get rid of A00global.

Initially, I thought about completely deleting or replacing the A00global file, but then I wondered if there were users who had modified it by adding their own global defaults to meet their own specific needs and use cases, and if so, I didn't want to simply delete/replace it. Adding a new global defaults file gives those users a chance to move/adjust their own custom defaults as they see fit, IMO.

Also, when Entware updates syslog-ng to 4.10, we'll be able to get rid of logrotate altogether, including the sighup

Thanks for the heads-up. Once the new 4.10.x version is released on Entware, I'll take a look at the changelog & documentation to see what's new and the API details to set up and configure its integrated "log rotation" mechanism.

 

[elorimer]

Initially, I thought about completely deleting or replacing the A00global file, but then I wondered if there were users who had modified it by adding their own global defaults to meet their own specific needs and use cases, and if so, I didn't want to simply delete/replace it. Adding a new global defaults file gives those users a chance to move/adjust their own custom defaults as they see fit, IMO.

Makes sense. Everything that had been in the standard A00 is in A01, so if someone has done their own A00 it will be overwritten by A01. If so, perhaps the standard A01global should be Aaglobal, so a custom A00global would redefine an option defined in Aaglobal.

 

[elorimer]

I'm puzzling over network sources and I haven't been able to get the syslog-ng.conf version to work.

Specifically, running on an AX-88 with .11 firmware, I have three Truenas servers set to send log messages to the AX-88 (one of which is over wireguard). I set them each to send the messages via UDP. In theory, the source statement in syslog-ng.conf ( udp(ip(192.168.x.y) port(514)); ) should work if the ip is that of one of the servers. And of course, I would need three udp definitions for that source, or three sources.

What does work is sending the messages over TCP. If I define the source as source net { syslog(ip(0.0.0.0) transport("tcp") port(514)); }; the traffic flows, including over wireguard. [I will pause and say if you ask Gemini how to send syslog-ng messages across wireguard, the answer won't work. Especially if you ask it to send syslog-ng messages across wireguard to an Asus router running AsusWRT-Merlin]. I can then use the netmask function to sort the servers into their separate log files.

I remember years ago I had this set up in the syslog-ng.conf way, and it worked fine. Something has changed, possibly in the firewall, to block UDP traffic on port 514. So if you have issues, try TCP.

 

[Martinski]

Release Notes for Scribe v3.2.7 production version now available
[2026-Jan-25]

1) FIXED: When the call to Scribe found in the '/jffs/scripts/unmount' script was made *after* the Entware services had been stopped, it failed to properly reset and put back the system log files so the built-in system loggers could then proceed to update them. This, in turn, was causing hundreds of log messages to be "lost" during a reboot sequence.

2) FIXED: Upon a system reboot, when Entware services are started, syslog-ng was shutting down the built-in system loggers too early and with a minimum 2-second delay (and perhaps more in some cases), causing hundreds (and possibly close to a thousand) of reboot log messages to be "lost" due to the "deluge" of log entries flooding the system logs within the first ~2 to ~3 minutes of the bootup process. Now, the start of the syslog-ng service is delayed for 150 seconds after "rc.unslung" is called to start all Entware services.

3) IMPROVED: Added 2-hour, 3-hour, and 4-hour intervals for the logrotate cron job schedule options. This allows users to set up a more frequent maximum-size rotation check to prevent a fast-growing log file from getting too big within just a handful of hours, well before reaching the default 24-hour frequency setting.

4) IMPROVED: Decreased the log message size to 2048 (from original 16384) in the top-level syslog-ng configuration file.

5) IMPROVED: Increased the log FIFO queue for the number of messages to 1024 (2048 if total RAM > 512MB) in the top-level syslog-ng configuration file.

6) IMPROVED: Improvements in the display of CLI menu options.

7) IMPROVED: Removed the "postrotate/endscript" directive from each logrotate configuration file available in the "/opt/share/logrotate/examples" directory since that's already defined in the global set of default directives. Make sure to answer 'y' when prompted to update the filter files during the version update.

8) Miscellaneous code improvements.


For users currently running any BETA development version, run the following commands to switch to the latest production release:

/jffs/scripts/scribe stable
/jffs/scripts/scribe forceupdate

Sample screenshots:

The following screenshot shows the message generated when the Scribe CLI menu is launched while waiting for the syslog-ng service to be started following a reboot. The wait may be up to 150 seconds if you log into an SSH terminal immediately after the router has rebooted, but before syslog-ng is started by the background process. Simply wait for the number of seconds shown in the message.

The fork from @cmkelley's Scribe add-on is now hosted on the AMTM-OSR GitHub repo:

GitHub - AMTM-OSR/scribe: Entware syslog-ng and logrotate installer for Asuswrt-Merlin

Entware syslog-ng and logrotate installer for Asuswrt-Merlin - AMTM-OSR/scribe

github.com

 

[XIII]

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

Is that intentional?

 

[scootertramp]

In case anybody else out there has the patience of a child and refuses to follow the guidance given.
When upgrading Scribe 3.2.6 to 3.2.7 I got the following message.

NOTICE:
 -------
 syslog-ng will start in about 140 seconds...
 Please wait until syslog-ng has been started.

     s. Show scribe status

     e. Exit scribe
    is. Reinstall scribe
    zs. Remove scribe

 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

 Please select an option:

So I waited what I thought was long enough. Figured show scribe couldn't hurt and got this.

      checking syslog-ng daemon ... alive.
    syslog.log default location ... /jffs/syslog.log
  ... & agrees with config file ... okay!

 checking system for necessary scribe hooks ...

          checking S01syslog-ng ... present.
         checking service-event ... present.
            checking post-mount ... present.
               checking unmount ... present.
    checking logrotate cron job ... present.
       checking directory links ...grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
/jffs/scripts/scribe: local: line 172: syslogNg_WaitnSEM_FPath: is read only
/jffs/scripts/scribe: local: line 172: syslogNg_StartSEM_FPath: is read only
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
 updated.

 checking syslog-ng configuration ...

   syslog-ng.conf version check ... in sync. (4.7)
    syslog-ng.conf syntax check ... okay!

          scribe installed version: v3.2.7 (master)
             scribe GitHub version: v3.2.7 (master)
                    scribe is up to date!

 Press <Enter> key to continue...

Got I little concerned when repeated attempts to show scribe showed the same output.
To temper my patience I decided it was time to get a coffee and come back and try again.
Had the same output so I restarted syslog-ng and all is well again.

On my next three routers I waited until I saw the following from my syslog server.

alertname Rsyslog application scribe_SysLogNg_Delay.sh_ component loki.source.syslog connect_host rt-be88u.dbonenet.com. detected_level warning facility user grafana_folder Alerts host rt-be88u hostname rt-be88u level warning message 2026-01-25T05:54:55-05:00 rt-be88u scribe_SysLogNg_Delay.sh_ 18390 - [meta sequenceId="1"] End of Background Script [scribe_SysLogNg_Delay.sh][18390] protocol udp service_name system-logs

None displayed any irregularities when selecting show scribe status.
There is a moral here, but I lack the willingness to wait.

 

[visortgw]

In case anybody else out there has the patience of a child and refuses to follow the guidance given.
When upgrading Scribe 3.2.6 to 3.2.7 I got the following message.

NOTICE:
 -------
 syslog-ng will start in about 140 seconds...
 Please wait until syslog-ng has been started.

     s. Show scribe status

     e. Exit scribe
    is. Reinstall scribe
    zs. Remove scribe

 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

 Please select an option:

So I waited what I thought was long enough. Figured show scribe couldn't hurt and got this.

      checking syslog-ng daemon ... alive.
    syslog.log default location ... /jffs/syslog.log
  ... & agrees with config file ... okay!

 checking system for necessary scribe hooks ...

          checking S01syslog-ng ... present.
         checking service-event ... present.
            checking post-mount ... present.
               checking unmount ... present.
    checking logrotate cron job ... present.
       checking directory links ...grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
grep: ^/opt/: No such file or directory
/jffs/scripts/scribe: local: line 172: syslogNg_WaitnSEM_FPath: is read only
/jffs/scripts/scribe: local: line 172: syslogNg_StartSEM_FPath: is read only
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
/jffs/scripts/scribe: line 172: /bin/grep:ELF: not found
 updated.

 checking syslog-ng configuration ...

   syslog-ng.conf version check ... in sync. (4.7)
    syslog-ng.conf syntax check ... okay!

          scribe installed version: v3.2.7 (master)
             scribe GitHub version: v3.2.7 (master)
                    scribe is up to date!

 Press <Enter> key to continue...

Got I little concerned when repeated attempts to show scribe showed the same output.
To temper my patience I decided it was time to get a coffee and come back and try again.
Had the same output so I restarted syslog-ng and all is well again.

On my next three routers I waited until I saw the following from my syslog server.

alertname Rsyslog application scribe_SysLogNg_Delay.sh_ component loki.source.syslog connect_host rt-be88u.dbonenet.com. detected_level warning facility user grafana_folder Alerts host rt-be88u hostname rt-be88u level warning message 2026-01-25T05:54:55-05:00 rt-be88u scribe_SysLogNg_Delay.sh_ 18390 - [meta sequenceId="1"] End of Background Script [scribe_SysLogNg_Delay.sh][18390] protocol udp service_name system-logs

None displayed any irregularities when selecting show scribe status.
There is a moral here, but I lack the willingness to wait.

Try rebooting router.

 

[scootertramp]

Try rebooting router.

Against my better judgement I rebooted the router. Someone has to see if the new scribe functionally works I guess.
Holy crap! Everything went sideways, no internet ,no add-ons displayed in the router webui and many other items not working.
I haven't dug in yet on what went wrong, but a second reboot seems to have cleared up all issues.

What better day to have some fun with snowmageddon on it's way.

 

[Martinski]

Release Notes for Scribe v3.2.8 production version now available
[2026-Jan-26]

1) FIXED: Modified code to prevent grep errors that may be generated when running "Show scribe status" while syslog-ng has not yet been started.

[Thanks to @scootertramp for reporting the problem - post #155]​

 

[elorimer]

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.

The point of @version is that syslog-ng will not use features introduced in a higher version. In truth, we could be at 3.5 with no change in functionality until we get to 4.10, so it doesn't really matter.

 

[visortgw]

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.

The point of @version is that syslog-ng will not use features introduced in a higher version. In truth, we could be at 3.5 with no change in functionality until we get to 4.10, so it doesn't really matter.

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