Scribe Scribe nvram log_path - what should it be?

[vibroverbus]

RT-AX68U running 388.6, generally runs great. AMTM and bunch of add-ons running fine.
Loads of Entware stuff installed working perfectly AFAICT.
I do seem to have periodic hiccups with log files and Scribe / uiScribe config getting a little borked.
When this happens I tend to get split entries and the ui log display doesn't work anymore as its stuck looking at the initial boot entries only.
Just did scribe uninstall/reinstall cycle and all works great now. That usually is the case. But this has happened before, like things get screwed up on updates maybe?
I think the symptom eminates from loss of the /tmp/sys-log.log symlink to /opt location but I stupidly didn't look at it before doing the reinstall, and wondering if there's a cause for that symptom....

My specific question is - what log_path should be set to (or does it not matter?)

Quick scan now (post reinstall) shows:
- symlink from /tmp/syslog.log -> opt/var/log/messages (not one for syslog.log-1 - that is a standard file entry)
- 'blocking directories' exist /jffs/syslog.log and syslog.log-1
- nvram log_path=/jffs

Scribe status is all happy at the moment (see below) but Is that nvram correct? Or would it be better if it was set to /tmp?
I see that the blocking directories are supposed to force redirect back to tmp but would it be better if the log_path pointed there in the first place?

TIA...

 

[elorimer]

Some routers are /jffs and some are /tmp. Scribe was updated a while ago to suss out when installed where it is on the particular router, and do the links accordingly. But it doesn't do anything with nvram, as far as I know. Leave it.

 

[vibroverbus]

Some routers are /jffs and some are /tmp. Scribe was updated a while ago to suss out when installed where it is on the particular router, and do the links accordingly. But it doesn't do anything with nvram, as far as I know. Leave it.

OK will do. Unless it keeps breaking on updates, in which case I might try changing NVRAM and see if that is the issue.

 

[elorimer]

Looking at the original post, you are somewhat messed up if your NVRAM is pointing to /jffs and scribe thinks it is /tmp. Scribe kills syslogd and starts syslog-ng pointed directly at the log sockets; it then copies the log so far into the messages file; then turns the default log locations into directories to interfere with the copying that the firmware might do. But if the firmware is writing the starting log to a location other than where scribe thinks it is, you will lose the starting part of the log, I think. Scribe also handles exiting syslog-ng and restoring the default log (and back again) and I think you will get messed up there, too.

If you've messed with the nvram variable maybe you can find out where the default log is on an AX68 by searching here and putting it back to where it was. But to be honest, I'd reset to defaults and start all over.

There is nothing in scribe and syslog-ng that fools with nvram.

 

[cmkelley]

From scribe's point of view, everything is working "as intended". The blocking directories are in /jffs where the system thinks they belong (hence the nvram pointing to /jffs).

As an aside, scribe does not write to nvram. In fact, it doesn't even use nvram to figure out where the syslog.log file is being stored; before syslogd is killed, the command that the firmware used to start syslogd is interrogated to see where it's putting the syslog.log file. I can't remember for sure if I didn't know there was a way to interrogate nvram to see where it thinks the syslog.log file should be, or if the nvram log_path variable is a recent addition to the router software, and I couldn't count on it being there. I have suspicion it's the latter though. I have no idea if anything besides syslogd uses the log_path variable.