[HOWTO] resetting event logs after upgrades with "keep settings"

Networking Solutions Suggestion
1

Fed up with pointless event logs after a rut upgrade with “keep settings” ?
Me too! over 8000 events dated year 2033!
(its 2026 today in case someone reads this in the future)

There seems to be no way to clear logs in the GUI so I had to revert to the shell (CLI)

This seems to have done the trick here, so sharing in case this helps someone else
out there:

As background:

The Events Log is backed by a SQLite database at /log/log.db, with separate tables per category (EVENTS, SYSTEM, NETWORK, CONNECTIONS). This is what System > Maintenance > Events Log reads from.

RutOS ships the lsqlite3 Lua binding but not the standalone sqlite3 CLI tool, so we clear it via a short Lua snippet instead.

How to:

  1. SSH into the router (or use System > Maintenance > CLI in the WebUI).

  2. Stop the logging service, so nothing writes to the db while you clear it:

   /etc/init.d/log stop
  1. Clear the tables via Lua (uses the lsqlite3 binding already present on the system):
 lua -e "
local sqlite3 = require(‘lsqlite3’)
local db = sqlite3.open(‘/log/log.db’)
db:exec(‘DELETE FROM EVENTS’)
db:exec(‘DELETE FROM SYSTEM’)
db:exec(‘DELETE FROM NETWORK’)
db:exec(‘DELETE FROM CONNECTIONS’)
db:exec(‘DELETE FROM sqlite_sequence’)
db:exec(‘VACUUM’)
db:close()
print(‘done’)
"

The DELETE FROM sqlite_sequence resets the autoincrement ID counters back to zero. Skip that line if you’d rather keep IDs continuous. The result should be a single line of “done” - if it is “>” you probably didnt include the last quote (")

Note too that SMS_COUNT is a separate table used for SMS usage/limit tracking, not log entries - so I left it alone)

  1. Restart the logging service:
/etc/init.d/log start
  1. Confirm it’s running:
ps | grep log

(the log init script on this firmware doesn’t appear to support a status action, so ps is the quickest sanity check)

  1. Refresh the Events Log page in the WebUI — it should now show “This section contains no values yet.”

Notes

If you only want to clear specific entries (e.g. just the bad-timestamp ones) rather than wiping everything, you can add a WHERE clause to the DELETE statements instead, e.g.

DELETE FROM EVENTS WHERE time > strftime(‘%s’,‘2030-01-01’)

Future-dated log entries are usually a symptom of a bad GPS time fix or brief NTP hiccup feeding a garbage timestamp into the system clock momentarily — worth keeping an eye out for recurrence if your device relies on GPS time sync.

I tested this on a RUTX11, firmware RUTX_R_00.07.23.7. - with the system time validated via date command as correctly set

I believe (other opinions are available) that this should apply to other RutOS/RUTX devices on similar firmware versions, though exact table names could vary slightly by device/firmware.

Hope this tidies things up for other people.

Regards

BB

1 Like