Clear System Logs - General Logs not working after updating to 384.17

[Natty]

I had updated firmware from 384.16 to 384.17 a few hours earlier. Everything seemed ok, but I had just switched OFF Enable Share in USB Application - Network Place (Samba) Share / Cloud Disk and I was investigating an interesting looking new error I'd noticed in the General Log:

httpd: nvram_check fail: nvram computer_name over length (16 > 15)

In Network Place (Samba) Share / Cloud Disk the Device Name was RT-AC66U_B1-F108, which had 16 characters, so I deleted a character from the last three numbers, saved and rebooted. Before rebooting, I cleared the general log so it would be easier to find if the nvram check fail was gone.

Upon reboot, the general log was full of original entries from days ago when I first flashed 384.16. I tried "Clear" again, but the same old stuff came back. Some of the more recent entries had gone though. Out of curiosity, I opened a text editor and looked at a backup I had made of the JFFS Partition, saved in file backup_jffs.tar. Inside this file I can see plain text corresponding to entries in the System Log - General Log.

I'm guessing the General Log is saved to the JFFS Partition, and that Clear did not delete all log entries from JFFS, maybe because of the firmware update? The old cruft looks to be stuck in the log permanently. How can I get a clean and shiny new system log?

The original 16 char Device Name was the default value, or system generated. The nvram check error seems to have been fixed by shortening the Device Name to 15 chars. Will there be any consequences of renaming the Device Name?

 

[dave14305]

I cleared my system log while watching the files in SSH and I saw the /tmp/syslog.log* files disappear, but the /jffs/syslog.log* remain. Eventually /jffs/syslog.log was overwritten, but /jffs/syslog.log-1 still remains and probably will until the /tmp/syslog.log rolls over to a new file. So if I rebooted, I expect the old /jffs/syslog.log-1 will be copied back to /tmp/syslog.log-1 and appear again in the GUI.

 

[Natty]

I cleared my system log while watching the files in SSH and I saw the /tmp/syslog.log* files disappear, but the /jffs/syslog.log* remain. Eventually /jffs/syslog.log was overwritten, but /jffs/syslog.log-1 still remains and probably will until the /tmp/syslog.log rolls over to a new file. So if I rebooted, I expect the old /jffs/syslog.log-1 will be copied back to /tmp/syslog.log-1 and appear again in the GUI.

If I understand, that neatly explains my observation that "Clear" doesn't clear?

The "Clear" behaviour seems like a bug to me, though I'm new here and maybe the syslog stuff is as it is supposed to be. Can someone please confirm?

I do not have ssh enabled, but might a possible workaround be to edit the backup_jffs.tar file and replace syslog.log and syslog.log-1 with blank versions, then restore the edited backup_jffs.tar file? Or simply delete the log files from the archive before restoring and and the system will generate new ones? Or is it advisable not go messing around with the JFFS backup?

I noted comments on the thread https://www.snbforums.com/threads/r..._8-are-now-available.63636/page-3#post-576098 about "dirty flashing" to update firmware. I'm guessing that's what I did, and perhaps that's why my router's JFFS is in a mess. Is there a way to clean it up so the logs have a clean start?

 

[dave14305]

I think it's a bug only in the sense that the "watchdog" process doesn't pay any attention to differences in the /jffs/syslog.log-1 file (it's not supposed to be changing once it rolls to the log-1 file, so in theory no need). But on a clear, I would like to think it should remove the /jffs copies also.

I suggest enabling SSH temporarily, logging in and running:

ls -l /tmp/syslog.log* /jffs/syslog.log*

If there is still a /jffs/syslog.log-1 file, but no /tmp/syslog.log-1 file, run this command to "sync" them:

rm /jffs/syslog.log-1

Then run a fresh JFFS backup in the GUI.

There's nothing inherently bad in dirty flashing, despite the name. Unless you run into stability problems...which you have not. Just syslog OCD.

 

[elorimer]

I think a lot of people observe the trick of making the /jffs logs into directories so they don't get written to in the first place.

 

[Natty]

Thanks @dave14305, I'll give that a try. I was hoping I could manage everything through the web UI, but I guess I can blow the dust off PuTTY and do it via ssh.

@elorimer : the log directory trick you mention sounds interesting. Apologies I am a noob as afar as Asus routers and asuswrt-merlin are concerned. Would you mind explaining or linking to how I would do that?

 

[elorimer]

@elorimer : the log directory trick you mention sounds interesting. Apologies I am a noob as afar as Asus routers and asuswrt-merlin are concerned. Would you mind explaining or linking to how I would do that?

Pretty good explanation from the scribe script that starts syslog-ng:

   # make /jffs/syslog.log and log-1 directories if not already
    # prevents system log saver from writing to jffs
    if [ ! -d "/jffs/syslog.log" ] || [ ! -d "/jffs/syslog.log-1" ]
    then
        rm -rf /jffs/syslog.log /jffs/syslog.log-1
        mkdir /jffs/syslog.log /jffs/syslog.log-1
    fi

 

[Natty]

Thanks @elorimer. I have no idea what syslog-ng is, nor that scribe script you refer to. Am I to infer I need to edit a script to prevent system logs being written to jffs? I'm happy to give it a go, but I'm coming to this forum in a state of almost total ignorance, so I would appreciate further guidance.

@dave14305: ssh worked and the old unwanted log is now cleared. But won't that logfile just keep growing bigger and bigger, expanding the jffs partition until something breaks? Or is the size managed somehow?

The Asus user manual for the RT-AC66U-B1 states that "system log is cleared when the router is rebooted or switched off". That behaviour sounds ideal for ordinary users like me. Is one of the differences between asuswrt-merlin and stock Asus firmware in saving the logfile in jffs? That might be useful to developers who need a log to examine if a router crashes. However, I don't want to have to keep cleaning out enormous logfiles every few weeks, especially if the only way to do so is to login by ssh and run commands. I think I need to get the trick that @elorimer outlined working.

A temporary / permanent log persistence switch in the GUI would be a useful feature.

 

[dave14305]

@dave14305: ssh worked and the old unwanted log is now cleared. But won't that logfile just keep growing bigger and bigger, expanding the jffs partition until something breaks? Or is the size managed somehow?

The maximum size for each log is 256 KB, so 512 KB maximum combined size.

 

[elorimer]

I'm not sure this is much of a problem, but if you don't want the syslog copied into /jffs, then SSH into the router and run those two commands in the snippet I quoted: the rm command to remove those two files, and then the mkdir command to create two directories with those names in /jffs. The firmware won't be able to write the copies into /jffs anymore.

The rest of the snippet is just code to say if those files exist, then run those commands; if they don't exist then it had already been done.

 

[Natty]

I'm not sure this is much of a problem, but if you don't want the syslog copied into /jffs, then SSH into the router and run those two commands in the snippet I quoted: the rm command to remove those two files, and then the mkdir command to create two directories with those names in /jffs. The firmware won't be able to write the copies into /jffs anymore.

Thanks for clarifying. I now understand how to deploy that trick. Also thanks @dave14305 for clarifying the maximum logfile size. I can see why it is not worth worrying about.

It would be nice if the GUI "Clear" function does what it says on the tin, or if the persistence could be user selectable. But I guess I'll just live with it as-is and stop worrying.