@sdetweil – Yes, I did.
The output I pasted included 2 runs. The first returned an access error as expected. The 2nd run says ‘not a minidump file’.
I guess I confused things by pasting all that. Sorry.
@sdetweil – Yes, I did.
The output I pasted included 2 runs. The first returned an access error as expected. The 2nd run says ‘not a minidump file’.
I guess I confused things by pasting all that. Sorry.
@sdetweil – OK, well… The program DID install (I was surprised , given what has been happening…). This resulted in an error. I specified that large file we identified earlier. Do let me know if I did the wrong thing. See results below.
While you are looking at this, I am going to fire up the other, older VM that also crashed and see if there is similar evidence there that might shed light.
JohnGalt@MM-Dev-VM:~/MagicMirror$ sudo npm install -g electron-minidump
[sudo] password for JohnGalt:
added 29 packages in 34s
1 package is looking for funding
run `npm fund` for details
npm notice
npm notice New major version of npm available! 10.9.4 -> 12.0.2
npm notice Changelog: https://github.com/npm/cli/releases/tag/v12.0.2
npm notice To update run: npm install -g npm@12.0.2
npm notice
JohnGalt@MM-Dev-VM:~/MagicMirror$ electron-minidump -f /var/lib/apport/coredump/core._home_al_MagicMirror_node_modules_electron_dist_electron.1000.f1d1264a-f2d2-4a44-8b27-e2f3182e030f.380943.121091464
Error: EACCES: permission denied, open '/var/lib/apport/coredump/core._home_al_MagicMirror_node_modules_electron_dist_electron.1000.f1d1264a-f2d2-4a44-8b27-e2f3182e030f.380943.121091464'
at async Object.open (node:internal/fs/promises:641:25)
at async electronMinidump (/usr/local/lib/node_modules/electron-minidump/index.js:11:14) {
errno: -13,
code: 'EACCES',
syscall: 'open',
path: '/var/lib/apport/coredump/core._home_al_MagicMirror_node_modules_electron_dist_electron.1000.f1d1264a-f2d2-4a44-8b27-e2f3182e030f.380943.121091464'
}
JohnGalt@MM-Dev-VM:~/MagicMirror$ sudo electron-minidump -f /var/lib/apport/coredump/core._home_al_MagicMirror_node_modules_electron_dist_electron.1000.f1d1264a-f2d2-4a44-8b27-e2f3182e030f.380943.121091464
Not a minidump file (MDMP header not found): /var/lib/apport/coredump/core._home_al_MagicMirror_node_modules_electron_dist_electron.1000.f1d1264a-f2d2-4a44-8b27-e2f3182e030f.380943.121091464
JohnGalt@MM-Dev-VM:~/MagicMirror$
JohnGalt@MM-Dev-VM:~/MagicMirror$ grep version package.json
"version": "2.35.0",
JohnGalt@MM-Dev-VM:~/MagicMirror$ grep version node_modules/electron/package.json
"version": "41.2.0"
Well, there’s this under /var/lib/apport/coredump:
Name:
core._home_al_MagicMirror_node_modules_electron_dist_electron.1000.f1d1264a-f2d2-4a44-8b27-e2f3182e030f.380943.121091464
Size:
40,486,436,864
is that file [just] a record of the dump[s]?
Put differently, would it be safe to delete the file or directory?
[Edit]: On further recollection - this appears to be happening only on the two VMs running MM, and not on the two Raspberry Pis that I have MM running on.
Does this represent a clue as to what is happening?
@sdetweil – true. I’m not sure I know to find that out…
@sdetweil – I will do that. I was just down the rabbit hole, using df. It looks like a huge amount is taken up by /var/lib/apport/coredump. See below:
JohnGalt@MM-Dev-VM:~/.pm2/logs$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 794M 1.1M 793M 1% /run
/dev/sda2 49G 49G 0 100% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
efivarfs 56K 27K 25K 52% /sys/firmware/efi/efivars
/dev/sda1 300M 7.8M 292M 3% /boot/efi
tmpfs 794M 92K 794M 1% /run/user/1000
JohnGalt@MM-Dev-VM:~/.pm2/logs$ cd ..
JohnGalt@MM-Dev-VM:~/.pm2$ cd ..
JohnGalt@MM-Dev-VM:~$ sudo du -h --max-depth=1 /var | sort -h | tail -n 10
4.0K /var/metrics
4.0K /var/opt
28K /var/crash
40K /var/spool
68K /var/tmp
5.4M /var/backups
49M /var/cache
617M /var/log
39G /var
39G /var/lib
JohnGalt@MM-Dev-VM:~$ sudo du -h --max-depth=1 /var/lib | sort -h | tail -n 10
772K /var/lib/systemd
2.0M /var/lib/fwupd
3.8M /var/lib/command-not-found
4.2M /var/lib/aspell
7.5M /var/lib/ubuntu-advantage
40M /var/lib/swcatalog
92M /var/lib/dpkg
276M /var/lib/apt
38G /var/lib/apport
39G /var/lib
JohnGalt@MM-Dev-VM:~$ sudo du -h --max-depth=1 /var/lib/apport | sort -h | tail -n 10
38G /var/lib/apport
38G /var/lib/apport/coredump
JohnGalt@MM-Dev-VM:~$ sudo du -h --max-depth=1 /var/lib/apport/coredump | sort -h | tail -n 10
38G /var/lib/apport/coredump
JohnGalt@MM-Dev-VM:~$
@sdetweil – Thanks, Sam. It looks like that won’t work - for the same reason as above. I need to give this some more thought… I can’t be the first person to encounter this issue. See below for the output of trying to install ncdu:
JohnGalt@MM-Dev-VM:~/.pm2/logs$ sudo apt install ncdu
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
ncdu
0 upgraded, 1 newly installed, 0 to remove and 33 not upgraded.
Need to get 50.7 kB of archives.
After this operation, 117 kB of additional disk space will be used.
E: You don't have enough free space in /var/cache/apt/archives/.
JohnGalt@MM-Dev-VM:~/.pm2/logs$
@sdetweil – Thanks Sam. See below for the output of the file sizes there.
JohnGalt@MM-Dev-VM:~/.pm2/logs$ ls -laF
total 32988
drwxrwxr-x 2 al al 4096 Apr 12 11:24 ./
drwxrwxr-x 5 al al 4096 Aug 19 12:09 ../
-rw-rw-r-- 1 al al 27348992 Aug 17 23:33 MagicMirror-error.log
-rw-rw-r-- 1 al al 6413424 Aug 17 23:27 MagicMirror-out.log
Query: What would cause a MagicMirror installed on a VM to fill up the 50 GiB VM virtual disk over 4 months?
I have an instance of MagicMirror installed in a Linux VM running under TrueNAS, which is mostly used to try out modules, configurations or layouts without disturbing the main MagicMirror. When I went to look at it yesterday I found the VM running, but not MM. PM2 status did not show it running, and it would [re]start. MagicMirror is the only thing installed on the VM, and running modules were newsfeed and default weather [5 instances],
Some searching tells me the virtual disk of 50 GiB is full! I have expanded the virtual disk size [resized the zvol], but am unable to extend the partition and filesystem as I get an error. I think it was along the lines of “you don’t have enough free space in /var/cache/apt/archives”.
At this point it appeared the best route would be to just build a new VM and install MM, but when I went to start making notes to record what I was doing - I found this same thing happened some months ago. The current VM is an upsized VM that similarly locked up.
Since starting over will not apparently solve the underlying root cause, I need some help. Thanks in advance.
@joey – Yes, it is still working for me.
As a cross-check I just visited several websites that purport to track pollen levels, and verified the module appears to be reporting relatively the same pollen levels. Each site appears to have its own scale and they don’t all appear to measure the same pollen particles - so direct comparison is difficult - but the MagicMirror module appears to be working.
For reference, following is the config I use for this module:
{module: "MMM-Pollen", // https://github.com/vincep5/MMM-Pollen
disabled: false, position: "top_right", header: "Pollen Forecast",
config: {
updateInterval: 5 * 60 * 60 * 1000, // every 5 hours
zip_code: "xxxxx" }
},
I hope this helps.
@thartley – Follow Sam’s instructions.
I am traveling so didn’t get to finish mine. I got to a point where I got a message that the action was in progress, but it would never finish. After some research I’m pretty sure I have a permission problem and will check it out when I get home in a couple of weeks.
@sdetweil --Hi Sam
That was a while ago and my memory is foggy, but the issue was mapping a share on my NAS to the Raspberry Pi on which the MM is running…
As best I recall, I tried following directions to map the drive, but it didn’t work. I seem to recall being left with the sense that the process [a] had changed over time due to changes in distributions, and/or [b] that there was something left out of the directions that were likely too obvious to mention for someone who already knew, but was non-obvious to someone out of the know. At that point I gave up.
Fast forward to today - I’m happy to invest the time to learn and get it done if you’re willing to help!! I appreciate it. I sent you an email regarding how to best proceed.
@sdetweil – Well, I’m not surprised. I have the pictures on a USB drive attached to the raspberry pi, and the more pictures on the drive the worse it gets. It does feel like the software is loading up memory with the pictures.
I tried some time ago pulling the pictures from a share on my NAS, (you had advised someone to do that on another thread) but I never got that to work.
Thanks for letting us know about the memory issue.
@wyovino – Ok, good to know.
One of my magic mirrors stops every few days. There is only one module running on that mirror, MMM-BackgroundSlideshow, so it’s obvious when it happens.
Bill, I’m glad you found what you were looking for.
I’m curious - what issue are you addressing by restarting the MagicMirror daily?
I read this thread with interest because I too have thought about resorting to daily restarts on one of my mirrors. [I’ve figured out that daily restarts won’t meet my needs / fix my problem - so I haven’t gone down that road (yet). I guess I could design a cron schedule that staggers the restart enough that the photo display doesn’t show the same pictures every day, but not yet…]
@plainbroke – Thanks. I have used FEH in the past. I used it as a dedicated picture display on a Raspberry Pi, but had issues with it being stable. I am now using Magic Mirror running a single module now for the same purpose. It stopps displaying pictures every few days, so I suspect I have too many pictures loaded on the USB mounted there. I may give FEH a try again…
Thanks again
@plainbroke – Just out of curiosity, what picture display program do you use?
@MikeTheYeti – Yes, I recall having the same or similar issues way back when…
I liked the idea of special effects for holidays, birthdays, scheduled vacation trips, etc - but couldn’t get it to work properly.
I eventually just gave up.