Can't connect to Moonraker after a power loss

General Discussion
41

Hi again, so today i went thru Mainsail deployment and did study documentation …

You should try to do following:

  1. select some non-working machine
  2. check which IP address it has now
  3. if you already did bind static IP to your machines in DHCP - fine, keep it this way, just reboot all of them so they will obtain defined IP addresses, if not - ok, can be that way.
  4. go to desired machine via ssh
  5. restore Mainsail config.json file to original state, most probably it was like this:
{
    "defaultLocale": "en",
    "hostname": null,
    "port": null,
    "instancesDB": "moonraker",
    "instances": []
}
  1. try to open Mainsail in browser by typing IP address of that machine, don’t use some name like “Delta.local”

I’m expecting that it should work, but if not, try to modify port in config.json file to value 7126 and try again opening your mainsail by IP address.

42

Tested with your suggestions, still not connecting.

I tried to connect to the machine from two different devices.

Screenshot 2024-05-09 125908

43

I may have fixed it!

I remembered having a similar issue when first trying to get Klipper working.
The issue was related to the klippy.sock path.

I checked the moonraker.conf file to verify the path.
I had a generic path like “~printer_data/comms/klippy.sock”
(this path worked just fine until the power loss)

I made it more exact by changing it to “/home/delta/printer_data/comms/klippy.sock”

I can now connect! Not sure why the klippy.sock path would work for days/weeks, then not work after the power loss.

Maybe someone can explain this?

44

  1. your path “~printer_data/comms/klippy.sock” is not correct, because it’s missing leading slash, it should be “~/printer_data/comms/klippy.sock”, most probably moonraker was capable to process it.

  2. Issue with path can explain issues between moonraker and klipper connection, but according to your moonraker.log - you didn’t have issue with path, your fix don’t have any relation to issue between Mainsail and Moonraker connection - at least I don’t see any relation.

  3. Great that you can connect now, but I’m not sure that you did fix the real issue with your fix.

Question: which way you did connect to Mainsail ?
by IP or by Name ?

45

I just forgot the first slash when typing it HERE. The slash was present in the conf.file.

I can connect by both IP and name. Not sure which I did first.

I did only one thing at a time. then rebooted machine.
After changing the klippy.sock path, the machine connected!
I don’t know how else to explain it.
Previous to that, I edited the “trusted clients”. I added “192.168.1.0/24” and removed all others.

46

Your last moonraker.conf file which you did post from non-working machine
already did contain full path also it did have 192.168.0.0/16 in trusted_clients that address include 192.168.1.0/24

So as i said - your fix is not relevant to your original issue.
Most probably your issue went away because of you did bind IP to machine and eventually that IP address did propagate everywhere and issue temporary went away, but issue can be back again eventually.

beginning from your posted moonraker.conf file

[server]
host: 0.0.0.0
port: 7126
klippy_uds_address: /home/bravo/printer_data/comms/klippy.sock

[authorization]
trusted_clients:
    192.168.1.10
    10.0.0.0/8
    127.0.0.0/8
    169.254.0.0/16
    172.16.0.0/12
    192.168.0.0/16
    FE80::/10
    ::1/128
47

That was from my other machine that I already reinstalled.

The IP was already binded when the issue happened.

I really thought I figured it out!

Wish I knew what changed for sure.

Frustrating.

48

Yea, Frustrating …
But i know what was happening and how to avoid it in future.

To explain issues first I will describe how Mainsail-Moonraker-Klipper is properly working.

  1. When you enter some Address in Browser (like Delta or Delta.local) browser will try to resolve it to IP address, when it’s successful resolved by some subsystems (there are many different sub-systems involved in this resolvent) then browser will go to that IP and try to fetch a default Web page from that IP.
  2. When Mainsail is installed on machine then it’s considered as that Default Web page.
  3. So when Browser load default (Mainsail) web page it will kick additional actions to load additional resources for Mainsail UI, one of those resources will be that config.json file.
  4. When Mainsail UI will load that config.json file - it will analyze it and will take decision what to do.
    By default that file have property hostname set to null - this will tell Mainsail UI to search moonraker instance in same address which you did enter in browser, also by default it contain property port set to null - this will tell mainsail UI to use standard Moonraker port 7125.
  5. Now when Mainsail know where to search moonraker it will connect there and starts communicating with moonraker with it’s language, query printer data, send commands, etc…
  6. Moonraker will convert them to klipper language and will interact with klipper thru defined connection (klippy.sock file).

This describes what should be happening in normal properly working system.

Now what was happening in your case:
When you did install and configure some machine you did define it’s name, for example it was “Delta”.
While you was installing all require software and configuration that name “Delta” name did propagate thru your network to your PC and did bring it’s current IP address with it.
You did finish setup and configuration and everything is working properly - Great.

Now when that “Delta” system did experienced reboot or power failure it was booted again but this time it did receive other IP address from your router DHCP system.
When you did try to open it again in browser there could be 2 outcomes,
First possible outcome - when your browser try to resolve that “Delta” to IP address it can resolve it to old IP address because it didn’t propagate to your PC, in this scenario your browser will not load Mainsail UI at all and you will get general connection timeout error.
Second possible outcome is that your browser will resolve that “Delta” name to new IP address and start loading Mainsail UI from new IP address, but when it try to reach moonraker - it can’t because connecting there is done thru other sub-system called websockets which are using other methods to resolve that “Delta” name and it’s resolving it to old IP address.
Those short names (like “Delta”) are very unreliable by themselves and very often propagation of that name can stuck in some sub-systems but when you additionally have Dynamic addresses, propagation of new IP address is even worse. There is a possibility to make them reliable - but it require special complex services for that and additional proper complicated configuration of network in each device.

When you bind IP address to specific device - this will help eventually when that name will propagate everywhere with latest IP and you will not experience additional issues with IP changes.

I usually suggest to avoid this kind of issues all together by using only IP addresses, don’t use those short names, they are very unreliable.
When you are using IP addresses - then browser and all sub-system don’t doo that resolvent at all, they bypass that naming systems and immediately go to that IP address.

You can say - I did try to use direct IP address in browser to open Mainsail, but it still didn’t see moonraker !
I have explanation for this case also:
It was happening because you have mismatched port settings in mainsail config.json and moonraker.conf, i did see that in files and screenshots which you did post.
when mainsail config.json file have port attribute set to null - this will tell Mainsail UI that moonraker should be on it’s default network port 7125, but some of your moonraker.conf files specify other port number, so in this kind of scenario moonraker is waiting on some customized port like 7126 but Mainsail is trying to connect on default port 7125 - and it can’t see moonraker there.

To check/fix this issues you should analyze each system independently.
Check which port is defined in moonraker.conf and check which port is defined in Mainsail config.json
if moonraker.conf file specify default port as 7125, then you can have port value null in config.json, if moonraker.conf have some other value - you need to put same value in config.json

Sorry for long post, I’m just trying to explain everything what is happening for you or somebody else who will be reading this in future.

49

Thank you for the very thorough reply.
I think many will benefit from it.
I think there is more going on with my situation than what you have graciously explained.

My other machine (which was also affected after the power loss) did not resolve the connection issue by adjusting the same parameters, so I reinstalled everything AGAIN on that machine.

Now that machine fails to load part of the network infrastructure, so I can’t even connect to it via SSH. I even tried a new microSD card, same issue.

During all my web browsing regarding this issue, I have found that Klipper does NOT recommend the Raspberry Pi Zero at all. This may be a significant contributing factor.
If the Pi is getting overloaded, there is a possibility of file corruption. Perhaps the file corruption is causing the config corruption which is causing the connection issues.

I often found corrupted “databases” listed on the “machine” tab of Mainsail’s interface on all machines.

I decided to order “Raspberry Pi zero 2 W’s” this morning. The “zero 2 W’s” have a four core processors to handle Klipper more efficiently.

We’ll see if the new hardware helps! I will report back.

Thanks again for all your efforts and contributions! I really do appreciate your time!

  • Mat
50

I would connect HDMI monitor to Rpi and would look what is happening there …

Seems unreasonable, I would understand that all filesystem can become corrupted and systems can’t boot, or written files get’s corrupted but not configs - config are usually only reading, reading of a file in most cases can’t corrupt filesystem.

Klipper itself don’t need some high performant machine, for example i use single core 1Ghz CPU on BeagleBone Black board, which is happily driving Delta printer with Moonraker+Fluidd and load on CPU usually is pretty low.

51

This is how I found out why I couldn’t ssh into the machine anymore. Has a “failed to load” some network related component. Reinstalled again. same issue.

52

I know I am a week late but here are some things to consider once you replace your hardware and are setting it up.

Make sure each machine has a different hostname. You can set it using sudo hostnamectl set-hostname

You should always assign static IP address at the router not on the Pi. Make sure the static IP you assigned is not in the pool of ips the DHCP server hands out for the dynamic ip range or you can run into arp cache issues. My DHCP server ip pool starts at 100, below that are my static ip addresses.

If you’re accessing the machine using something like printer-name.local and have issues, switch to http://ip-address. Bonjour is used to register .local names and can be slow to register them.

I have an ASUS mesh Wifi network and my Pi’s don’t always play well with it. Wifi connection would randomly drop and I could not connect without a reboot. I added a script to monitor connectivity to router which restarts the Wifi connection after n failed pings which solved that issue.

This script runs from cron and pings router to check connection, restarts wifi interface if it’s down.

53

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.