What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Scribe Scribe v3.2.5 [2025-Nov-23] - Entware syslog-ng and logrotate installer for Asuswrt-Merlin

Code:
Gilly@ripshod:/tmp/home/root# ls -al /jffs/syslog.log
lrwxrwxrwx    1 Gilly    root            21 Nov 28 16:17 /jffs/syslog.log -> /opt/var/log/messages
 
Please select an option: s

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

On both rt-be88u and xt-8's
On second thought, I would perform Re-detect syslog.log location within scribe Utilities to see if it cleaned things up and created symbolic links. Empty directories definitely do not make sense...
 
On second thought, I would perform Re-detect syslog.log location within scribe Utilities to see if it cleaned things up and created symbolic links. Empty directories definitely do not make sense...
Good catch.

agagne@rt-be88u:/tmp/home/root# ls -al /jffs/syslog.log
lrwxrwxrwx 1 agagne root 21 Nov 29 15:37 /jffs/syslog.log -> /opt/var/log/messages

Now it looks normal.
 
Good catch.

agagne@rt-be88u:/tmp/home/root# ls -al /jffs/syslog.log
lrwxrwxrwx 1 agagne root 21 Nov 29 15:37 /jffs/syslog.log -> /opt/var/log/messages

Now it looks normal.
Now try a reboot, see if it sticks.
 
Good catch.

agagne@rt-be88u:/tmp/home/root# ls -al /jffs/syslog.log
lrwxrwxrwx 1 agagne root 21 Nov 29 15:37 /jffs/syslog.log -> /opt/var/log/messages

Now it looks normal.
Doesn't change anything on my xt-8's. But they have a vaild symlink in /tmp/syslog.log

agagne@xt8-up:/tmp/home/root# ls -la /jffs/syslog.log
drwxrwxrwx 2 agagne root 0 Nov 29 15:40 .
drwxr-xr-x 16 agagne root 0 Nov 29 15:40 ..
agagne@xt8-up:/tmp/home/root# ls -la /tmp/syslog.log
lrwxrwxrwx 1 agagne root 21 Nov 29 15:40 /tmp/syslog.log -> /opt/var/log/messages
 
The following output is ordered by execution time...
Code:
Please select an option: rd

 Detecting default syslog location...
 Briefly shutting down syslog-ng
Done.
 Starting syslog-ng...              done.
Code:
Please select an option: s

      checking syslog-ng daemon ... alive.
    syslog.log default location ... /tmp/syslog.log
  ... & agrees with config file ... okay!
Code:
# ls -al /jffs/syslog*
/jffs/syslog.log:
drwxrwxrwx    2 atr      root             0 Nov 29 23:38 .
drwxr-xr-x   17 atr      root             0 Nov 29 23:38 ..

/jffs/syslog.log-1:
drwxrwxrwx    2 atr      root             0 Nov 29 23:38 .
drwxr-xr-x   17 atr      root             0 Nov 29 23:38 ..
Code:
# ls -al /tmp/syslog*
lrwxrwxrwx    1 atr      root            21 Nov 29 23:48 /tmp/syslog.log -> /opt/var/log/messages
-rw-rw-rw-    1 atr      root            24 Nov 29 23:48 /tmp/syslog.log-1
In the end, I just did a router reboot, and nothing above changed.
 
Now I'm left to ponder where it all went south.

1) upgrade scribe to 3.2.4 on all routers
2) switch the rt-be88u to scribe 3.2.5 Beta due to killl log messages
3) upgrade scribe to 3.2.5 on all routers.
4) The big one. FW upgrade on rt-be88u to 3006.102.6 from 3006.102.6 Beta.

Not gonna lose any sleep over it. Everything worked throughout.
Time for something cold.
 
4) The big one. FW upgrade on rt-be88u to 3006.102.6 from 3006.102.6 Beta.
Same router, same upgrade route - no problems. Never ran the scribe beta.
I'll join ya 🍺
 
The following output is ordered by execution time...
Code:
Please select an option: rd

 Detecting default syslog location...
 Briefly shutting down syslog-ng
Done.
 Starting syslog-ng...              done.
Code:
Please select an option: s

      checking syslog-ng daemon ... alive.
    syslog.log default location ... /tmp/syslog.log
  ... & agrees with config file ... okay!
Code:
# ls -al /jffs/syslog*
/jffs/syslog.log:
drwxrwxrwx    2 atr      root             0 Nov 29 23:38 .
drwxr-xr-x   17 atr      root             0 Nov 29 23:38 ..

/jffs/syslog.log-1:
drwxrwxrwx    2 atr      root             0 Nov 29 23:38 .
drwxr-xr-x   17 atr      root             0 Nov 29 23:38 ..
Code:
# ls -al /tmp/syslog*
lrwxrwxrwx    1 atr      root            21 Nov 29 23:48 /tmp/syslog.log -> /opt/var/log/messages
-rw-rw-rw-    1 atr      root            24 Nov 29 23:48 /tmp/syslog.log-1
In the end, I just did a router reboot, and nothing above changed.
Older routers did not use /jffs/syslog.log, but rather they used /tmp/syslog.log — I'm not sure at what point Asus switched to /jffs.
 
Older routers did not use /jffs/syslog.log, but rather they used /tmp/syslog.log— I'm not sure at what point Asus switched to /jffs.
Thank you for confirming! By sharing my router output, I just wanted to make sure that things are fine in my setup, and help others in future searches for comparison between setups.
I'm already aware that Asus made this switch some time ago, but I wasn't sure to which age my router belongs.
 
What does the Show scribe status command (i.e., s.) within scribe show for syslog.log default location?
Code:
 Please select an option: s

      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 ... present.

 checking syslog-ng configuration ...

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

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

 Press <Enter> key to continue:

Does ls -al /jffs/syslog.log show the symbolic link?
Code:
# ls -al /jffs/syslog.log
lrwxrwxrwx    1 TheS1R   root            21 Nov 29 09:32 /jffs/syslog.log -> /opt/var/log/messages
I ran some commands you asked for:

Screenshot from 2025-11-29 13-41-55.pngScreenshot from 2025-11-29 13-46-47.pngScreenshot from 2025-11-29 13-59-31.pngScreenshot from 2025-11-29 14-02-25.pngScreenshot from 2025-11-29 14-08-58.png
 
Last edited:
The screenshots and output shown in your latest post look correct, and they indicate that your Scribe setup is currently configured as expected. If your JFFS partition continues to get filled up again, I suspect it might be caused by something else, but perhaps it leads to a corruption in the Scribe functionality.

I have a custom shell script that I've used before as a diagnostic tool to monitor cases when either the TMPFS or the JFFS file system was being filled up slowly with large files over a period of a few weeks. IIRC, the last time was about 2 years ago, where the Traffic Monitor (or Traffic Analyzer??) was generating a very large database file (a little over 40MB). The log file generated by the diagnostic script and stored in the USB-attached drive showed the database file slowly increasing and filling the JFFS partition during the previous 3 weeks.

In your particular case, I don't really know what's causing the problem, but you could set up the diagnostic script to run as a cron job at a fixed interval (e.g. every 20 mins or every 4 hours), depending on how fast the JFFS is getting filled up and, hopefully, the log file will capture some rogue file(s) getting larger over time.

You can use the following commands to download the custom script from my personal GitHub repo:
Bash:
curl  -LSs --retry 3 --retry-delay 5 --retry-connrefused \
https://raw.githubusercontent.com/Martinski4GitHub/CustomMiscUtils/master/Diags/LogMemoryStats.sh \
-o /jffs/scripts/LogMemoryStats.sh && chmod a+x /jffs/scripts/LogMemoryStats.sh

Once downloaded into the router, type the following command:
Bash:
/jffs/scripts/LogMemoryStats.sh -help
The output will provide some useful CLI syntax to set up the cron job and other parameters to configure the diagnostic script for your own specific needs. Try to run the script by itself first to see the kind of output that gets generated, and if you're willing to let it run as a cron job, execute the call to set it up with your preferred time interval. If you want the cron job to persist across reboots, copy & paste the given command at the end of your '/jffs/scripts/post-mount' hook script.

Example call:
Bash:
/jffs/scripts/LogMemoryStats.sh -setcronjob 1hour

HTH.
 
Over the past few months, I've seen several posts from uiScribe users mentioning, suggesting, or asking about the ability to rotate or "clear" the log files on demand. Given that some of the log files appear to grow very fast and much larger than the size directive should allow (I don't know why), I started working on a solution.

Below is a screenshot from last night of what I have implemented so far:

uiScribe_v1.4.10_WebUI_Rotate&ClearLogs.jpg


The above screenshot was taken some time after clicking on the "Clear All" button.

The idea is to allow users to either rotate or clear each log individually or all at once. The log file sizes are also displayed so that users can check when a log file is growing too large. I'll have more information later about the new features, so this is just a quick FYI for now.
 
This is a great idea. Can I suggest, while you are into that, that you have a go at changing the message for a zero-size log and a bigly size log? Now, if the log is too big, uiScribe displays a message that the log file cannot be found; it displays the same message if a log file exists but is of zero length (i.e. right after rotating). Both are wrong and send you in the wrong direction for troubleshooting. This solution addresses that with the size display, so maybe it only needs to suppress the incorrect message when the file exists.
 
Not sure I'm following all this, but scribe implements an old Merlin trick of changing the firmware default log files to directories. The firmware writes (wrote?) the logs to /tmp and copied it to /jffs, and this prevents unnecessary wear on the /jffs location. The trick dates back to the very first versions.

 
Last edited:

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top