Read the statement by Michael Teeuw here.
Upgraded, failed back, now mirror constantly restarts
-
@ember1205 how did u restore the changes to package.json? the script stashed the old package.json file so that the upgrade could continue
-
Umm… git stash pop?
I renamed the upgraded install to “MM-Upgraded” and then renamed my copied directory back to “MagicMirror”. Neither of them works properly at this point and the copied directory was never touched during the upgrade process.
-
@ember1205 ok, can’t do that… poackage.json is version specific
u might not need it as that run-start.sh was for older configs…
restore with
git checkout package.jsonMMM-ImagesPhotos update was because of the missing request lib… removed in 2.16 (you were on 2.13)
I dont see anything else in the upgrade that should be problematic…
try with the default package.json
-
Forgive me, but “can’t do” what, exactly?
I have reverted to the exact software, install, and configuration that was in place before running the upgrade by renaming the upgraded directory and then renaming the backed up directory back to the original name. Unless there are files downloaded and stored -outside- of the MagicMirror directory, this should have ensured a complete reversion to the working files.
-
@ember1205 but I see a current version of node and npm, which would not have been available in 2.13 timeframe…
the old install will not run on the new node and npm , and a new npm install on the old folder
-
The device is restarting for what appears to be out of memory / swap space issues. Every time the system crashes and restarts, /dev/shm is at zero available space.
This location appears to be where the processes are storing content from the image files that are being loaded and it’s apparently causing something to overrun the available space. I have added images, but that was a couple of weeks ago (before even applying the OS updates) and everything ran perfectly fine.
-
@ember1205 df -k will show you what is used
the top looks like this
Filesystem 1K-blocks Used Available Use% Mounted on udev 24555800 0 24555800 0% /dev tmpfs 4931772 4108 4927664 1% /run /dev/nvme0n1p1 1921217360 889131676 944193092 49% / tmpfs 24658844 1769768 22889076 8% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 24658844 0 24658844 0% /sys/fs/cgroupwith appropriate names for your system
free -m will show u memory and swap space
-
Pretty sure it’s an out of memory issue. Once it crashes, the free memory jumps way up then trends back down once it restarts.
I’ve also discovered that this seems to be purely a “client” problem as I can connect to the Pi from a remote machine using a web browser and it will run just fine without any hiccups while the local client on the Pi crashes about every 60-70 seconds which correlates to two load intervals for photos. Maybe the MMM-ImagesPhotos module isn’t releasing memory properly?
-
After a LOT of different attempts at upgrades, fail-backs, new installs, etc., I believe I finally corrected the issue…
It appears that PM2 was either somehow corrupted during an update attempt or just simply too far out of date. Attempting to run PM2 with certain command options (like stop or even status) was resulting in errors indicating some sort of circular reference. After doing a forced upgrade to the latest version, it stopped showing these errors and the mirror is to running as expected.
I did make some additional changes that include copying the core MM directory off to another linux host where I now run the mirror as a server. The RPi is now purely a client and it loads noticeably quicker as a result.
-
@ember1205 thx. I will add checking pm2 to the upgrade script
