@sdetweil
EDIT: I was digging while cleaning up pm2 so it didn’t display my old script. I noticed that the mm.sh script in ~/MagicMirror/installers was indeed missing export ELECTRON_DISABLE_GPU=1. Adding that back to the script seems to keep it stable. Still wondering if this is an Electron version issue.

No dice. Here are the errors I am seeing in the logs - I pulled only the errors to see if I caught them all. Here is what I am seeing at the exit event:

0|mm  | [25978:1009/112505.776458:ERROR:zygote_communication_linux.cc(275)] Failed to send GetTerminationStatus message to zygote
0|mm  | [25978:1009/112505.812741:ERROR:zygote_communication_linux.cc(275)] Failed to send GetTerminationStatus message to zygote
0|mm  | [25978:1009/112505.848727:ERROR:network_service_instance_impl.cc(470)] Network service crashed, restarting service.
0|mm  | [25978:1009/112505.880738:ERROR:gpu_process_host.cc(968)] GPU process launch failed: error_code=1002
0|mm  | [25978:1009/112505.897587:ERROR:gpu_process_host.cc(968)] GPU process launch failed: error_code=1002
0|mm  | [25978:1009/112505.917812:ERROR:gpu_process_host.cc(968)] GPU process launch failed: error_code=1002
0|mm  | [25978:1009/112505.942511:ERROR:gpu_process_host.cc(968)] GPU process launch failed: error_code=1002
0|mm  | [25978:1009/112505.959337:ERROR:gpu_process_host.cc(968)] GPU process launch failed: error_code=1002

And later in the restart process I saw these errors:

0|mm  | [09.10.2022 11:25.36.393] [ERROR] 
0|mm  | (node:26362) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
0|mm  | (Use `electron --trace-deprecation ...` to show where the warning was created)

I did go in and check for the line export ELECTRON_DISABLE_GPU=1 in the startup script mm.sh and it is there. I did have two startup scripts (one that was created before your script was a a thing) and made sure it was there in both as I wasn’t sure which pm2 was using. The original is out in the home folder - I made a backup and then ran your pm2 setup script. While it seemed to reconfigure pm2 to use the script in ~/MagicMirror/installers it still crashes. Figured I would try that in case something was walking over itself.

Could this be an Electron version issue?

@sdetweil
node v16.16.0
npm v8.11.0

I am running on a Raspberry Pi B3+

@sdetweil
Still seems to crash. This is how I have configured my pm2 start script:

cd ~/MagicMirror
export ELECTRON_DISABLE_GPU=1
DISPLAY=:0 npm start

@sdetweil
Output of first command is:

Linux raspberrypi 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux

Output of second command is:

No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

I did so a manual upgrade. Though I typically do that without running into too many issues.

After updating my MagicMirror to version 2.21.0 it seems that Electron is crashing when using PM2 with the following error at crash (from pm2 logs):

0|mm  | /home/pi/MagicMirror/node_modules/electron/dist/electron exited with signal SIGTERM

After the restart there seems to be a large number of errors thrown, though with a repeating pattern of the following:

0|mm       | [30696:1006/101030.900201:ERROR:angle_platform_impl.cc(43)] renderergl_utils.cpp:2519 (CheckError): GL call functions->texStorage2D(ToGLenum(type), static_cast<GLsizei>(levels), texStorageFormat.internalFormat, size.width, size.height) generated error 0x00000505 in ../../third_party/angle/src/libANGLE/renderer/gl/TextureGL.cpp, setStorage:1052.
0|mm       | [30696:1006/101030.901706:ERROR:shared_context_state.cc(811)] SharedContextState context lost via Skia OOM.
0|mm       | [30696:1006/101030.903252:ERROR:gpu_service_impl.cc(990)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
0|mm       | [19587:1006/101030.932806:ERROR:command_buffer_proxy_impl.cc(329)] GPU state invalid after WaitForGetOffsetInRange.
0|mm       | [19587:1006/101030.940181:ERROR:gpu_process_host.cc(974)] GPU process exited unexpectedly: exit_code=8704
0|mm       | MESA-LOADER: failed to retrieve device information
0|mm       | MESA-LOADER: failed to retrieve device information
0|mm       | MESA-LOADER: failed to retrieve device information

Now, if I run MagicMirror by using npm start while in the ~/MagicMirror directory, it seems to stay up. Hoping someone has some insight on this. I can easily manually start the system, but would rather not have to every time.

@sdetweil Gotcha, like I said limited knowledge with JavaScript. These changes indeed worked. Thank you!

I figured the actual function of testing whether to add or remove was heavy - if not bad practice. This was a “can I make this work?” type of thing. I will definitely rework this - since I would like to make it lighter on the browser. I don’t really know where to begin, but the internet has great resources (I’m also going to start taking some programming courses at work - I work at a University).

@sdetweil This worked, thank you! I had not read that far back into the changelog. There were a few others that seem to have been removed that I needed.

I am now running into another issue, maybe you can help. I wrote a cheap and dirty “module”, really it’s not, that changes my color scheme for day/night. Since updating I am getting this error in Chrome (on PC - not sure what my mirror is displaying however the function seems to be working), that I was not before: module tries to update the DOM without being displayed.. I get this every second - because I wrote the update interval to be that.

I am not too well versed on JavaScript, but understand some basic functions - learning more by the day :)
I am not sure where this error is originating, but I think it is in main.js by the console logs in Chrome. I can disable this module, as it was more a project that ended up working.

Here is my file for that “module”. This is it, it displays nothing.

/* Magic Mirror
 * Module: MMM-AutoThemes
 *
 * By Patrick Tanner
 * 
 */
Module.register("MMM-AutoThemes", {
        // Default module config.
        defaults: {
                darkTime: "1830",
                lightTime: "0630",
                updateInterval: 1000,
        },

        start: function () {
                Log.info("Starting module: " + this.name);
                var self = this;
                var dark = this.config.darkTime;
                var light = this.config.lightTime;

                Log.info("Start Dark " + dark + ' ' + "Start Light " + light);

        setInterval(function() {
                self.updateDom();
                },
                this.config.updateInterval);
        },

        getDom: function autoThemes() {
                var h = new Date().getHours();
                var m = new Date().getMinutes();
                var dark = this.config.darkTime;
                var light = this.config.lightTime;

                h = h < 10 ? "0" + h : h;
                m = m < 10 ? "0" + m : m;
                var time = h + '' + m;

                if (dark < light) {
                        if (time >= dark && time < light) {
                                document.body.classList.add("dark-mode");
                                document.body.classList.remove("light-mode");
                        } else if (time < dark || time >= light) {
                                document.body.classList.remove("dark-mode");
                                document.body.classList.add("light-mode");

                }} else if(dark > light){
                        if (time >= dark || time < light) {
                                document.body.classList.add("dark-mode");
                                document.body.classList.remove("light-mode");
                        } else if (time < dark && time >= light) {
                                document.body.classList.remove("dark-mode");
                                document.body.classList.add("light-mode");

                }
        }
        },

Just did an update to the newest version of MM (2.17.1). Made sure to reinstall everything needed, and went into each module folder to do npm install where needed. I got a blank screen. Fine, it’s happened before so I did some updating and troubleshooting. No dice.
Here is the warning from the output I am getting when I run npm start dev.

[03.10.2021 16:34.46.191] [ERROR] WARNING! Could not load config file. Starting with default configuration. Error found: Error: Cannot find module 'valid-url'
Require stack:
- /home/pi/MagicMirror/modules/MMM-CalendarWeek/node_helper.js
- /home/pi/MagicMirror/js/app.js
- /home/pi/MagicMirror/js/electron.js
- /home/pi/MagicMirror/node_modules/electron/dist/resources/default_app.asar/main.js
-

This is the only error. I am uncertain what is actually going on here. Not sure if it is telling me that these four modules have target files moved (they shouldn’t), or if there is some module it’s trying to load I don’t have installed. Or if there is a line missing in my config.

When running npm run config:check I get:

[03.10.2021 16:35.42.348] [INFO]  Checking file...  /home/pi/MagicMirror/config/config.js
[03.10.2021 16:35.42.461] [INFO]  Your configuration file doesn't contain syntax errors :)

So…that’s fine as far as syntax.

Just need some guidance on what to do next. I’m much of a “figure it out before asking for help” kind of person. I just don’t know what Require stack: means, or rather how to do it or search for solutions.

In case anyone else seems to struggle with this weird issue, I have found that if you use the “non-standard” approach of using the month name rather than number, it works.

Here is what I mean. This is my config for all my “MMM-Snow” module iterations:

{
module: "MMM-Snow",
position: "fullscreen_above",
classes: "scheduler",
config: {
              module_schedule: {from: "0 0 1 DEC *", to: "59 11 31 DEC *"},
              theme: "winter"
              }
},
{
module: "MMM-Snow",
position: "fullscreen_above",
classes: "scheduler",
config: {
              module_schedule: {from: "0 0 14 FEB *", to: "0 0 15 FEB *" },
              theme: "love"
               }
},
{
module: "MMM-Snow",
position: "fullscreen_above",
classes: "scheduler",
config: {
              module_schedule: {from: "0 0 12 DEC *", to: "0 0 27 DEC *"},
              theme: "xmas"
              }
},
{
module: "MMM-Snow",
position: "fullscreen_above",
classes: "scheduler",
config: {
             module_schedule: {from: "0 0 17 MAR *", to: " 0 0 18 MAR *"},
             theme: "stpattys"
             }
},
{
module: "MMM-Snow",
position: "fullscreen_above",
classes: "scheduler",
config: {
              module_schedule: {from: "0 0 25 OCT *", to: "0 0 1 DEC *"},
              theme: "fall"
              }
},

Here is my log output (only a selection, that’s been chopped up) on reload:

...

MMM-ModuleScheduler is removing all scheduled jobs
MMM-ModuleScheduler has completed the send job for REMOTE_ACTION based on "30 7 * * 1-5"
MMM-ModuleScheduler has completed the send job for REMOTE_ACTION based on "0 17 * * 1-5"
MMM-ModuleScheduler has completed the send job for REMOTE_ACTION based on "0 4 8,18,28 * *"
MMM-ModuleScheduler has completed the show job for module_3_MMM-Snow based on "0 0 1 DEC *"
MMM-ModuleScheduler has completed the hide job for module_3_MMM-Snow based on "59 11 31 DEC *"
MMM-ModuleScheduler has completed the show job for module_4_MMM-Snow based on "0 0 14 FEB *"
MMM-ModuleScheduler has completed the hide job for module_4_MMM-Snow based on "0 0 15 FEB *"
MMM-ModuleScheduler has completed the show job for module_5_MMM-Snow based on "0 0 12 DEC *"
MMM-ModuleScheduler has completed the hide job for module_5_MMM-Snow based on "0 0 27 DEC *"
MMM-ModuleScheduler has completed the show job for module_6_MMM-Snow based on "0 0 17 MAR *"
MMM-ModuleScheduler has completed the hide job for module_6_MMM-Snow based on " 0 0 18 MAR *"
MMM-ModuleScheduler has completed the show job for module_7_MMM-Snow based on "0 0 25 OCT *"
MMM-ModuleScheduler has completed the hide job for module_7_MMM-Snow based on "0 0 1 DEC *"

...

MMM-ModuleScheduler received CREATE_MODULE_SCHEDULE
MMM-ModuleScheduler is scheduling MMM-Snow using "0 0 17 MAR *" and " 0 0 18 MAR *" with dim level undefined    
MMM-ModuleScheduler is hiding MMM-Snow
MMM-ModuleScheduler has scheduled MMM-Snow
MMM-ModuleScheduler will next show MMM-Snow at Wed Mar 17 2021 00:00:00 GMT-0400 (Eastern Daylight Time)
MMM-ModuleScheduler will next hide MMM-Snow at Thu Mar 18 2021 00:00:00 GMT-0400 (Eastern Daylight Time)
MMM-ModuleScheduler received CREATE_MODULE_SCHEDULE
MMM-ModuleScheduler is scheduling MMM-Snow using "0 0 25 OCT *" and "0 0 1 DEC *" with dim level undefined
MMM-ModuleScheduler has scheduled MMM-Snow
MMM-ModuleScheduler will next show MMM-Snow at Mon Oct 25 2021 00:00:00 GMT-0400 (Eastern Daylight Time)
MMM-ModuleScheduler will next hide MMM-Snow at Tue Dec 01 2020 00:00:00 GMT-0500 (Eastern Standard Time)

...

I guess this is the way to fix this issue? I always thought that using “MAR” over “3” was considered bad, but maybe it’s the new standard and should be done? Either way, my “fall” snow is now displaying properly. Hope this helps some.

If someone knows why the standard Crontab is bumping up a month, and knows a solution, please feel free to add it here. I feel like this is an odd issue to have.

This is a bit of an odd one. I have several modules scheduled for various things, one of those being MMM-Snow to display various seasonal “snows”.

I added a fall one today and could not, for the life of me, get the snow to show when I added the module_schedule:{from:"* * * * *", to:"* * * * *"}, line. It would work if I commented that out, or removed the line classes: "scheduler",. So I went to the logs and found something weird.

Here is how it is actually written in the config:

{
module: "MMM-Snow",
position: "fullscreen_above",
classes: "scheduler",
config: {
        module_schedule: {from: "0 0 25 10 *", to: "0 0 29 11 *"},
        theme: "fall"
        }
},

This is what the pm2 logs say when I reload the mirror:
The “grab the schedules” bit:

1|mm  | [2020-11-10 11:58:44.045] [LOG]    MMM-ModuleScheduler has completed the show job for module_7_MMM-Snow based on "0 0 25 10 *"
1|mm  | [2020-11-10 11:58:44.046] [LOG]    MMM-ModuleScheduler has completed the hide job for module_7_MMM-Snow based on "0 0 29 11 *"

The “I’m scheduling now” bit:

[2020-11-10 11:49:49.572] [LOG]    
1|mm  | [2020-11-10 11:49:49.572] [LOG]    
1|mm  | MMM-ModuleScheduler has scheduled MMM-Snow
1|mm  | [2020-11-10 11:49:49.573] [LOG]    
1|mm  | MMM-ModuleScheduler will next show MMM-Snow at Wed Nov 25 2020 00:00:00 GMT-0500 (Eastern Standard Time)
1|mm  | [2020-11-10 11:49:49.574] [LOG]    MMM-ModuleScheduler will next hide MMM-Snow at Tue Dec 29 2020 00:00:00 GMT-0500 (Eastern Standard Time)

Not sure why the timestamp and log text are separated, but I can’t control that. You can see that the time I specify vs. the time it will be scheduled are exactly one month late. This happens for every module, EXCEPT those scheduled in December. I have several modules the appear and disappear based on time alone, and those all work as scheduled. It seems only the month variable is off kilt. Any thoughts?

P.S. There are no errors pertaining to MMM-ModuleScheduler being thrown.