Fatal error: Uncaught RedisException: MISCONF Redis is configured to save RDB snapshots, but it’s currently unable to persist to disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error. in /var/www/emoncms/Modules/user/user_model.php:1157 Stack trace: #0 /var/www/emoncms/Modules/user/user_model.php(1157): Redis->incr() #1 /var/www/emoncms/Modules/user/user_model.php(460): User->is_rate_limited() #2 /var/www/emoncms/Modules/user/user_controller.php(138): User->login() #3 /var/www/emoncms/core.php(111): user_controller() #4 /var/www/emoncms/index.php(258): controller() #5 {main} thrown in /var/www/emoncms/Modules/user/user_model.php on line 1157
and login fails.
Also any options on the LCD button menus are not available.
Switching off the power is the only way to reboot.
Following this i am able to login, so long as i do quickly.
I have found this message in the emoncms log:
2026-09-04 13:58:50.888|ERROR|emoncms_mqtt.php|RedisException: MISCONF Redis is configured to save RDB snapshots, but it’s currently unable to persist to disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error. in /var/www/emoncms/Modules/input/input_model.php:124
Stack trace: #0 /var/www/emoncms/Modules/input/input_model.php(124): Redis->hMset() #1 /var/www/emoncms/scripts/services/emoncms_mqtt/emoncms_mqtt.php(468): Input->set_timevalue() #2 [internal function]: message() #3 /var/www/emoncms/scripts/services/emoncms_mqtt/emoncms_mqtt.php(157): Mosquitto\Client->loop() #4 {main}
In the short period between reboot, login and the error appearing it does look like the unit is operating.
I have managed to get it working alot better.
I renamed /var/lib/redis/dump.rdb to add .old on the end, restarted and it has now been running the longest time since it went wrong.
What do you get if your run the following (my systems answers included here as examples)
pi@emonpi:~ $ redis-cli dbsize
(integer) 1111
pi@emonpi:~ $ redis-cli --bigkeys
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Biggest hash found so far '"input:644783"' with 5 fields
[00.00%] Biggest hash found so far '"feed:165231"' with 11 fields
[00.00%] Biggest string found so far '"hpctrl:temp"' with 4 bytes
[00.90%] Biggest zset found so far '"feed:165230:buffer"' with 28 members
[00.90%] Biggest string found so far '"emoncms_sync:feed_status:1"' with 22910 bytes
[28.89%] Biggest set found so far '"user:device:1"' with 21 members
[82.09%] Biggest set found so far '"user:feeds:1"' with 209 members
[98.56%] Biggest set found so far '"user:inputs:1"' with 309 members
-------- summary -------
Sampled 1111 keys in the keyspace!
Total key length in bytes is 17829 (avg len 16.05)
Biggest hash found '"feed:165231"' has 11 fields
Biggest string found '"emoncms_sync:feed_status:1"' has 22910 bytes
Biggest set found '"user:inputs:1"' has 309 members
Biggest zset found '"feed:165230:buffer"' has 28 members
0 lists with 0 items (00.00% of keys, avg size 0.00)
898 hashs with 4709 fields (80.83% of keys, avg size 5.24)
111 strings with 27040 bytes (09.99% of keys, avg size 243.60)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
4 sets with 637 members (00.36% of keys, avg size 159.25)
98 zsets with 2212 members (08.82% of keys, avg size 22.57)
Scanning the entire keyspace to find biggest keys as well as
average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
per 100 SCAN commands (not usually needed).
[00.00%] Biggest hash found so far ‘“input:133”’ with 5 fields
[00.00%] Biggest hash found so far ‘“feed:220”’ with 11 fields
[08.66%] Biggest string found so far ‘“diskstats:mmcblk0p3:write”’ with 7 bytes
[21.65%] Biggest string found so far ‘“diskstats:starttime”’ with 10 bytes
[30.30%] Biggest set found so far ‘“feed:bufferactive”’ with 53 members
[39.83%] Biggest set found so far ‘“user:feeds:1”’ with 60 members
[65.80%] Biggest string found so far ‘“admin:systeminfo”’ with 4071 bytes
-------- summary -------
Sampled 231 keys in the keyspace!
Total key length in bytes is 3140 (avg len 13.59)
Biggest hash found ‘“feed:220”’ has 11 fields
Biggest string found ‘“admin:systeminfo”’ has 4071 bytes
Biggest set found ‘“user:feeds:1”’ has 60 members
0 lists with 0 items (00.00% of keys, avg size 0.00)
216 hashs with 1146 fields (93.51% of keys, avg size 5.31)
11 strings with 4124 bytes (04.76% of keys, avg size 374.91)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
4 sets with 168 members (01.73% of keys, avg size 42.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
pi@emonpi:~ $ redis-cli config get save
1) "save"
2) "3600 1 300 100 60 10000"
pi@emonpi:~ $ redis-cli info persistence | grep -E 'rdb_last_bgsave_status|rdb_saves|rdb_changes' grep -n -E '^\s*#?\s*save' /etc/redis/redis.conf
grep: grep: No such file or directory
grep: ^\s*#?\s*save: No such file or directory
grep: /etc/redis/redis.conf: Permission denied
pi@emonpi:~ $ sudo sed -i -E 's/^\s*save\s/# &/' /etc/redis/redis.conf echo 'save ""' | sudo tee -a /etc/redis/redis.conf
sed: can't read echo: No such file or directory
sed: can't read save "": No such file or directory
############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.
appendonly no
# The base name of the append only file.
#
# Redis 7 and newer use a set of append-only files to persist the dataset
# and changes applied to it. There are two basic types of files in use:
#
# - Base files, which are a snapshot representing the complete state of the
# dataset at the time the file was created. Base files can be either in
# the form of RDB (binary serialized) or AOF (textual commands).
# - Incremental files, which contain additional commands that were applied
# to the dataset following the previous file.
#