syslog on jffs

[kjetilhp]

Just upgraded to the latest merlin build and enabled jffs, after boot I see that syslog.log is also located on jffs partition, is this correct? wouldn't this go against "(from wiki.. jffs page) I do not recommend doing frequent writes to this area, as it will prematurely wear out the flash RAM". Also located in /tmp and both are logged to.

 

[Marsi4eg]

The same 'problem'
not good to save logs to jffs....

 

[RMerlin]

This is a feature that was implemented by Asus with recent firmwares. Pretty sure the amount of write was deemed safe enough if their engineers decided to move syslog there.

 

[RMerlin]

One thing I did BTW was to disable it on the RT-N16 and RT-N66U, keeping it enabled only on devices with 32 MB of JFFS space. That way, it is highly unlikely that writing a few dozen bytes every day with wear levelling over 32 MB of flash multiplied by the thousands of possible write cycles per cell will wear out your nvram any time soon.

 

[NeutralGold]

One thing I did BTW was to disable it on the RT-N16 and RT-N66U, keeping it enabled only on devices with 32 MB of JFFS space. That way, it is highly unlikely that writing a few dozen bytes every day with wear levelling over 32 MB of flash multiplied by the thousands of possible write cycles per cell will wear out your nvram any time soon.

I was actually getting on here today to ask about that. After I read this post last night and checked my jffs partition and I didn't see a syslog file on there. You already answered my question with that post.

Thanks~

 

[saintdev]

I was actually getting on here today to ask about that. After I read this post last night and checked my jffs partition and I didn't see a syslog file on there. You already answered my question with that post.

Thanks~

Me too, lol.

 

[Finguz]

I am saving my syslog ( RT-N66U Merlin35_2-sdk5 )to a usb stick, and things seem to be working. However I keep getting the following message appearing in the logs..

Nov 28 22:35:22 cstats[25416]: Problem loading /mnt/sda1/RouterLog/tomato_cstats_60a44cd2a910.gz. Still trying...
Nov 28 22:35:22 rstats[25350]: Problem loading /mnt/sda1/RouterLog/tomato_rstats_60a44cd2a910.gz. Still trying...

The log appears to be saving ok, so is this something I should be worried about or just a bug?

 

[RMerlin]

I am saving my syslog ( RT-N66U Merlin35_2-sdk5 )to a usb stick, and things seem to be working. However I keep getting the following message appearing in the logs..

Nov 28 22:35:22 cstats[25416]: Problem loading /mnt/sda1/RouterLog/tomato_cstats_60a44cd2a910.gz. Still trying...
Nov 28 22:35:22 rstats[25350]: Problem loading /mnt/sda1/RouterLog/tomato_rstats_60a44cd2a910.gz. Still trying...

The log appears to be saving ok, so is this something I should be worried about or just a bug?

It means you enabled traffic monitoring and IPTraffic but didn't create the database (the option to do so are just below the options that let you enable both features).

 

[frankiech]

One thing I did BTW was to disable it on the RT-N16 and RT-N66U, keeping it enabled only on devices with 32 MB of JFFS space. That way, it is highly unlikely that writing a few dozen bytes every day with wear levelling over 32 MB of flash multiplied by the thousands of possible write cycles per cell will wear out your nvram any time soon.

Can we get an option to disable it on the AC68U?

Even following the other threads to move it to a USB drive I can't get the symlinks or syslogd changes to "stick" (even when the scripts work) -- it always starts creating the syslog in /jffs after awhile.

I'm concerned about the amount of writes to /jffs. Is there a reason Asus wanted syslogs in /tmp AND /jffs? Seems a little overkill. I'd rather just have it off completely...

 

[Finguz]

It means you enabled traffic monitoring and IPTraffic but didn't create the database (the option to do so are just below the options that let you enable both features).

Hehehe, conclusive proof that I'm a huge eejit! Not that any was required

Thanks Merlin

Edit: I selected yes to the relevant ones, as per the attached pic, yet I am still getting the load failed messages in the log?

Edit 2: Never mind, it seems all it needed was a reboot

 

[Rexcellent]

Mount /jffs to USB drive?

Can we get an option to disable it on the AC68U?

Even following the other threads to move it to a USB drive I can't get the symlinks or syslogd changes to "stick" (even when the scripts work) -- it always starts creating the syslog in /jffs after awhile.

I'm concerned about the amount of writes to /jffs. Is there a reason Asus wanted syslogs in /tmp AND /jffs? Seems a little overkill. I'd rather just have it off completely...

Apologies if I am resurrecting an dead thread, but wouldn't it be possible to unmount /jffs and remount it to a USB drive? Something like:

umount /jffs
mount -o rbind /mnt/USB/my_jffs /jffs

This seems to work manually but not from /jffs/scripts/init-start, presumably because the device is in use (running the script).

Is there another place to remount /jffs either before (or after) the /jffs/scripts run? /etc/mtab maybe?

Thanks.

 

[Chrysalis]

funny enough on my ac66u it never logged to my jffs, I wish it did as the default to ram is very bad with it been a tiny log file thats lost on every reboot.

Remember usb sticks are also flash memory and in addition flashing a firmware will be 1000s of more writes than the syslog ever will, so I think people have over reacted a bit.

 

[vjbalex]

@RMerlin re: your comment "One thing I did BTW was to disable it on the RT-N16 and RT-N66U..." Can you share how you disabled logging to jffs on those models? Nvram setting or something requiring build from source? I understand responses that writing to jffs is not a major concern however I just do not want the "feature",

374.41 running on Asus RT-AC68R.

 

[RMerlin]

@RMerlin re: your comment "One thing I did BTW was to disable it on the RT-N16 and RT-N66U..." Can you share how you disabled logging to jffs on those models? Nvram setting or something requiring build from source? I understand responses that writing to jffs is not a major concern however I just do not want the "feature",

374.41 running on Asus RT-AC68R.

This is configurable at compile time, by setting JFFS2LOG to "n" in the target profile.

 

[vjbalex]

This is configurable at compile time, by setting JFFS2LOG to "n" in the target profile.

Thank you for your reply and for all your wonderful work!

 

[john9527]

Any chance of making this configurable via an nvram variable?

 

[DavidEBSmith]

+1. Might be nice to be able to turn it on if there are issues like random reboots and leave it off normally.

 

[sfx2000]

This is a feature that was implemented by Asus with recent firmwares. Pretty sure the amount of write was deemed safe enough if their engineers decided to move syslog there.

Interesting - sooner or later, it will burn a hole in the flash - every write is actually two writes, and more than just the bytes written (flash one must first erase the cells, setting them to a known state, and then write the new data). The burning of the hole won't happen immediately, but it will happen, and probably after the warranty time expires, so the Asus Devs are probably ok with it, as long term, it'll sell more gear

I would have probably set up syslog into tmpfs instead, as it's more relevant post-bootup. Or mount a SDCard/USB Thumb drive and have syslog write there instead of to main flash.

(tmpfs is RAM for those who might be asking, it's not persistent...)

Having been there some time back with handset development where we did write something directly to flash, again thinking it won't be that often, we had devices fail in the field after about 3 months of flashing to the new firmware - a classic oops

sfx

 

[RMerlin]

Interesting - sooner or later, it will burn a hole in the flash - every write is actually two writes, and more than just the bytes written (flash one must first erase the cells, setting them to a known state, and then write the new data). The burning of the hole won't happen immediately, but it will happen, and probably after the warranty time expires, so the Asus Devs are probably ok with it, as long term, it'll sell more gear

The flash used by the RT-AC66U and newer models is rated for 100,000 PE cycles. It's in fact designed for frequent writes such as done by persistent logging.

 

[john9527]

Does this mean you won't consider selection via an nvram variable? At one point, it looked like you would (Issue #519).

BTW....I also tried changing the jffs copies to a symlink to /dev/null......this doesn't work. The symlink is deleted within a minute and replaced with a full copy of the syslog.