Scribe scribe 3.x_y - syslog-ng and logrotate installer

[Tarek Yag]

This brings up my previous question in post #213 again!

Guys, excuse me as I'm relatively new here. But, we're going to face this so many more times (people asking for a fix). Is there any way to propagate the scrollbar fix to the master branch for all affected Jack Yaz scripts? This will allow everyone to avoid a lot of headache.

 

[matthew_eli]

Hi, I've installed the develop version of Scribe (3.2.1) and I've been using the 3.2.0 on my RT-BE86U with 30006.102.2_Beta1 and if I restart scribe with rs command, my syslog is been flooded with the following entry every 3 seconds:

custom_script: Running /jffs/scripts/service-event (args: restart autowan)

Do you guys know why and how can I fix it?

EDIT: I tried to find "autowan" in both Scribe and uiScribe scripts, without any luck. Where is invoked the autowan restart?

 

[Martinski]

Guys, excuse me as I'm relatively new here. But, we're going to face this so many more times (people asking for a fix). Is there any way to propagate the scrollbar fix to the master branch for all affected Jack Yaz scripts? This will allow everyone to avoid a lot of headache.

Currently, AFAIK, with the exceptions of scMerlin & uiDivStats, all other @Jack Yaz's add-on releases are under his full control on their respective GitHub repositories. Someone would have to create a fork for each repo and take control by fixing bugs, maintaining source code when/if broken due to new F/W requirements, running validation testing on various router models & F/W versions, issuing master releases as needed, etc. Also, they would need to coordinate with @thelonelycoder so he can modify AMTM to adjust the "official" URLs from which each add-on stable/master release will be downloaded & installed.

While I do get some free time, mostly on some weekends (plus an hour here & there in the evenings during the regular work week) to look at a problem, fix it & submit a PR, I cannot fully commit to fixing/maintaining all of JackYaz add-ons. My current day job plus family responsibilities and other personal commitments don't leave me with enough free time to give the attention & focus that it would require to maintain the add-ons as an almost full-time hobby.

Here's a post from almost 2 years ago where I also explained the situation, and it has not really changed:

YazFi - YazFi and Routers with 6GHz band

This past evening, I was talking with one of my cousins, and he mentioned that he wanted to upgrade his almost 5-year-old RT-AC86U router and was thinking about getting a tri-band, or perhaps a quad-band, ASUS router. His current RT-AC86U is still working fine, but his network needs have grown...

www.snbforums.com

FYI.

 

[Tarek Yag]

@Martinski, I do appreciate your full explanation, and your time! All the best to you!
I hope that Jack Yaz could join us again some day, or someone could lead the development again.

 

[matthew_eli]

Hi, I've installed the develop version of Scribe (3.2.1) and I've been using the 3.2.0 on my RT-BE86U with 30006.102.2_Beta1 and if I restart scribe with rs command, my syslog is been flooded with the following entry every 3 seconds:

custom_script: Running /jffs/scripts/service-event (args: restart autowan)

Do you guys know why and how can I fix it?

EDIT: I tried to find "autowan" in both Scribe and uiScribe scripts, without any luck. Where is invoked the autowan restart?

in htop, the problematic process is:

/jffs/scripts/scribe service_event restart autowan

But I can't find it in the scribe script

 

[dave14305]

in htop, the problematic process is:

/jffs/scripts/scribe service_event restart autowan

But I can't find it in the scribe script

Autowan appears to be a firmware function for the new BE routers. Scribe is just reacting to the event, runs, but discards it since it isn’t related to Scribe.

Look in the Dual WAN section for “WAN Auto Detection” or something similar.

 

[visortgw]

Autowan appears to be a firmware function for the new BE routers. Scribe is just reacting to the event, runs, but discards it since it isn’t related to Scribe.

Look in the Dual WAN section for “WAN Auto Detection” or something similar.

Try explicitly setting "Primary WAN" within "WAN - Dual WAN" tab of WAN settings. Mine is set to "2.5G WAN/LAN" (set yours to your current WAN input) as opposed to "Auto WAN Detection" (default), and I don't see these errors.

 

[matthew_eli]

Hi, this is the current settings I have:

I don’t have auto settings in my case

 

[visortgw]

Hi, this is the current settings I have:

View attachment 62203

I don’t have auto settings in my case

And on my GT-BE98 Pro:

 

[matthew_eli]

So probably there is no autowan in RT-BE86U?

 

[visortgw]

So probably there is no autowan in RT-BE86U?

Asus says that autowan is available for device here.

 

[matthew_eli]

Then maybe there is an issue with FW? @RMerlin is that a normal behavior for you on RT-BE86U?

 

[matthew_eli]

Autowan appears to be a firmware function for the new BE routers. Scribe is just reacting to the event, runs, but discards it since it isn’t related to Scribe.

Look in the Dual WAN section for “WAN Auto Detection” or something similar.

Do you eventually know, as a workaround, how to kill that process from HTOP or in any other way? I tried to kill it in HTOP, but it's still resuming after sleep 1 command over and over again...

 

[dave14305]

Do you eventually know, as a workaround, how to kill that process from HTOP or in any other way? I tried to kill it in HTOP, but it's still resuming after sleep 1 command over and over again...

I don’t know what you see in htop, but as far as the log messages go, perhaps you can filter them using…Scribe!

 

[matthew_eli]

I don’t know what you see in htop, but as far as the log messages go, perhaps you can filter them using…Scribe!

It could work indeed...

Here is what Merlin replies about:

Constant "restart autowan" events are normal in 102_36xxx. They are hidden by Asus in the rest of the firmware, but will appear if you have custom scripts that reports on every single events. I can try to reapply their same workaround for service-event logging, but if scribe logs every single event, then it will be scribe's responsibility to also hide them if they are judged problematic.