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

OK, again the log has cleared upon reboot. Running the latest scribe:
Code:
 5  open     scribe                     3.2.4

I cleaned up the log a bit to remove lots of chatter with MAC addresses, and replaced mine:
Code:
cat messages | grep  -v DHCP[RADO] messages  |grep -v DROP |grep -v 'wlceventd_proc_event' | grep -v 'ovpn' |grep -v 'openvpn'

Not sure the clean log helps, but here it is attached.

Here is the relevant section of syslog-ng.log :
Code:
Nov 23 03:00:02 RT-AC86U-9988 syslog-ng[3368522]: Configuration reload finished;
Nov 23 04:00:02 RT-AC86U-9988 syslog-ng[3368522]: Configuration reload request received, reloading configuration;
Nov 23 04:00:02 RT-AC86U-9988 syslog-ng[3368522]: Configuration reload finished;
Nov 23 04:05:15 RT-AC86U-9988 syslog-ng[3368522]: syslog-ng shutting down; version='4.7.1'
Nov 23 04:06:47 RT-AC86U-9988 syslog-ng[2724]: syslog-ng starting up; version='4.7.1'
Nov 23 04:24:27 RT-AC86U-9988 syslog-ng[18664]: syslog-ng shutting down; version='4.7.1'
Nov 23 04:24:31 RT-AC86U-9988 syslog-ng[62424]: syslog-ng starting up; version='4.7.1'
Nov 23 04:24:33 RT-AC86U-9988 syslog-ng[62424]: Configuration reload request received, reloading configuration;
Nov 23 04:24:33 RT-AC86U-9988 syslog-ng[62424]: Configuration reload finished;
Nov 23 05:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload request received, reloading configuration;
Nov 23 05:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload finished;
Nov 23 06:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload request received, reloading configuration;
Nov 23 06:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload finished;
 

Attachments

What is "Scribe:kill_logger"?
Since between 10 and 11am yesterday and midnight last night my log was filled with those messages, to the point my "messages" file was bloated to over 1MB, at which point logrotate failed, my router ceased logging, disconnected all WiFi and refused new connections over LAN.

*edit* TL;DR I see this has been addressed 😁
 
Last edited:
Release Notes for Scribe v3.2.5 production version now available
[2025-Nov-23]


1) IMPROVED: Suppressed some of the syslog entries for the 'kill_logger' function calls.
[Thanks to @scootertramp for reporting the repeated syslog entries showing up in some "chatty" routers]​



The fork from @cmkelley's Scribe add-on is now hosted on the AMTM-OSR GitHub repo:
 
What is "Scribe:kill_logger"?
Since between 10 and 11am yesterday and midnight last night my log was filled with those messages, to the point my "messages" file was bloated to over 1MB, at which point logrotate failed, my router ceased logging, disconnected all WiFi and refused new connections over LAN.
It's a function that @cmkelley wrote to try to reset the syslog file paths and create the desired symbolic links to the new log files so that Scribe could work as expected.

Here's the comment from the script:
Bash:
# load kill_logger() function to reset system path links/hacks
 
But what causes it to suddenly fire off so suddenly and so frequently? Have you suppressed the function or just the messages?
 
OK, again the log has cleared upon reboot. Running the latest scribe:
Code:
 5  open     scribe                     3.2.4

I cleaned up the log a bit to remove lots of chatter with MAC addresses, and replaced mine:
Code:
cat messages | grep  -v DHCP[RADO] messages  |grep -v DROP |grep -v 'wlceventd_proc_event' | grep -v 'ovpn' |grep -v 'openvpn'

Not sure the clean log helps, but here it is attached.

Here is the relevant section of syslog-ng.log :
Code:
Nov 23 03:00:02 RT-AC86U-9988 syslog-ng[3368522]: Configuration reload finished;
Nov 23 04:00:02 RT-AC86U-9988 syslog-ng[3368522]: Configuration reload request received, reloading configuration;
Nov 23 04:00:02 RT-AC86U-9988 syslog-ng[3368522]: Configuration reload finished;
Nov 23 04:05:15 RT-AC86U-9988 syslog-ng[3368522]: syslog-ng shutting down; version='4.7.1'
Nov 23 04:06:47 RT-AC86U-9988 syslog-ng[2724]: syslog-ng starting up; version='4.7.1'
Nov 23 04:24:27 RT-AC86U-9988 syslog-ng[18664]: syslog-ng shutting down; version='4.7.1'
Nov 23 04:24:31 RT-AC86U-9988 syslog-ng[62424]: syslog-ng starting up; version='4.7.1'
Nov 23 04:24:33 RT-AC86U-9988 syslog-ng[62424]: Configuration reload request received, reloading configuration;
Nov 23 04:24:33 RT-AC86U-9988 syslog-ng[62424]: Configuration reload finished;
Nov 23 05:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload request received, reloading configuration;
Nov 23 05:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload finished;
Nov 23 06:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload request received, reloading configuration;
Nov 23 06:00:02 RT-AC86U-9988 syslog-ng[62424]: Configuration reload finished;
I reviewed your log and didn't see anything that stood out as the source of a possible issue. Then again, keep in mind that I actually don't use Scribe in my own routers on a continuous basis, so my experience with it is limited to a few temporary runs (for a day or two at a time) for development and testing purposes.

What I'd suggest now is to update to the latest production release v3.2.5, and the next time you reboot, capture the syslog covering the entire sequence of events during the bootup, and also run the following command without making any changes to Scribe:
<CODE>
/jffs/scripts/scribe debug
<CODE>
Then post the 'scribe_debug.log' file that gets generated.

Or could it be impacted by 'uiScribe' update? I did that update at the same time as scribe originally.
Note that uiScribe only reads the log files for displaying or downloading purposes; there's no other interaction with the log files.
 
But what causes it to suddenly fire off so suddenly and so frequently?
Good question. I don't know why in some routers, under some circumstances, the 'service-event' is called very often and repeatedly, one after the other, within a few minutes, which triggers the function calls.

Have you suppressed the function or just the messages?
The log entries were suppressed when triggered by a 'service-event' call.
 
Last edited:
It's a function that @cmkelley wrote to try to reset the syslog file paths and create the desired symbolic links to the new log files so that Scribe could work as expected.
Originally, kvic wrote it. It used to be something simple that killed syslogd and klogd, started syslog-ng, and stopped writing to the /tmp logs and created the symbolic links. Hence the name. Then there was a bit added by cmkelley to detect whether the log was in /tmp or /jffs. Now there is a whole lot that could be set and forget for a particular router, or at least moved to scribe and not S01.
 
I’m not sure what’s going on but my JFFS is completely filled and causing my router to essentially crash. I can’t even look at logs in the routers GUI because it locks up my routers GUI.

I tried to delete the logs after I SSH into the router but still having problems. This is the second time this has happened to me in a two weeks.

I’m not even sure it’s scribe causing it but that’s what I think maybe the reason. Please correct me if I’m wrong.

Here are some screen shots. I really have no idea how to process except trying to delete the logs to get the JFFS down to a normal size so my router doesn’t freeze up.

IMG_7563.png
IMG_7564.jpeg
IMG_7565.jpeg
 
See what’s taking up space:
Code:
du -a /jffs/ | sort -rn | head -20
/usr/bin/lsof | grep /jffs
My router was so unstable I deleted the logs and reclaimed the space. I have the feeling this will happen again soon though so I took note of the commands you listed and will use them if it happens again. I'll upload the output then. Thanks for responding.
 
Originally, kvic wrote it. It used to be something simple that killed syslogd and klogd, started syslog-ng, and stopped writing to the /tmp logs and created the symbolic links. Hence the name. Then there was a bit added by cmkelley to detect whether the log was in /tmp or /jffs. Now there is a whole lot that could be set and forget for a particular router, or at least moved to scribe and not S01.
Ah, got it. Thanks for the correction. I'm not aware at all of the history behind the development of the Scribe and uiScribe add-ons. The top header of the shell script does mention that code was borrowed from a few SNBForums contributors, but there are no names associated with the functions, so it's rather impossible to tell who originally wrote what and when; hence, my assumption that @cmkelley was who wrote that specific function. :oops:;)
 
My router was so unstable I deleted the logs and reclaimed the space. I have the feeling this will happen again soon though so I took note of the commands you listed and will use them if it happens again. I'll upload the output then. Thanks for responding.
Note that Scribe (using syslog-ng and logrotate) does not write any logs to the JFFS partition; everything goes to the USB-attached drive; all log files specifically are written to the '/opt/var/log' directory. It appears to me that something else might be going on, which results in filling up the JFFS partition.

BTW, how large were the log files? And, were those logs located in the '/opt/var/log' directory as expected?
 
My router was so unstable I deleted the logs and reclaimed the space. I have the feeling this will happen again soon though so I took note of the commands you listed and will use them if it happens again. I'll upload the output then. Thanks for responding.
Run it every now and then to see if something is slowly growing.
 
Here is the output of those commands, which I have no idea what they mean:

View attachment 69212
The first command is showing the sizes of the top 20 largest files/directories. See if it changes significantly tomorrow. The second command is showing which processes have open files on /jffs, just as a check of what might be writing regularly.
 
Note that Scribe (using syslog-ng and logrotate) does not write any logs to the JFFS partition; everything goes to the USB-attached drive; all log files specifically are written to the '/opt/var/log' directory. It appears to me that something else might be going on, which results in filling up the JFFS partition.

BTW, how large were the log files? And, were those logs located in the '/opt/var/log' directory as expected?
Hello,

I ran Scribe when my router was on the verge of crashing, and I noticed it said something like "no space left here" in relation to syslog.log. It pointed to the location: /jffs/syslog.log. So, I deleted that log, thinking it might help clear up some space.

After deleting it, I saw that my JFFS partition shrunk down to around 1.5MB instead of being completely full at 45MB. I’m not sure if I did something wrong, but I mainly did it because people in my house were reporting issues with the router, though I don’t know exactly what happened on their end. I’m guessing they were having connection problems, but I'm not sure.

For me the router’s GUI was essentially frozen and completely unresponsive and even SSH was really slow with AMTM items taking forever to load.

I just wanted to reach out to clarify what happened in case deleting /jffs/syslog.log caused any unintended side effects or if I need to do something else to prevent this in the future.

thanks
 
Hello,

I ran Scribe when my router was on the verge of crashing, and I noticed it said something like "no space left here" in relation to syslog.log. It pointed to the location: /jffs/syslog.log. So, I deleted that log, thinking it might help clear up some space.

After deleting it, I saw that my JFFS partition shrunk down to around 1.5MB instead of being completely full at 45MB. I’m not sure if I did something wrong, but I mainly did it because people in my house were reporting issues with the router, though I don’t know exactly what happened on their end. I’m guessing they were having connection problems, but I'm not sure.

For me the router’s GUI was essentially frozen and completely unresponsive and even SSH was really slow with AMTM items taking forever to load.

I just wanted to reach out to clarify what happened in case deleting /jffs/syslog.log caused any unintended side effects or if I need to do something else to prevent this in the future.

thanks
I take it you're not using a usb drive?
With a small directory as /jffs I would definitely recommend using one.
Mystery how your syslog got so large in the first place.
 

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