{"id":631,"date":"2024-01-31T20:39:40","date_gmt":"2024-02-01T04:39:40","guid":{"rendered":"https:\/\/www.mattjm.com\/blog\/?p=631"},"modified":"2024-01-31T20:39:40","modified_gmt":"2024-02-01T04:39:40","slug":"prind-broken-after-unexpected-shutdown","status":"publish","type":"post","link":"https:\/\/www.mattjm.com\/blog\/2024\/01\/31\/prind-broken-after-unexpected-shutdown\/","title":{"rendered":"Prind Broken After Unexpected Shutdown"},"content":{"rendered":"\n

I use prind<\/a> to run my 3d printer. I’ve had this happen twice now where I get this error after an unexpected shutdown (like a power outage):<\/p>\n\n\n\n

“Moonraker can’t connect to Klipper! Please check if the Klipper service is running and klippy_uds_address is correctly configured in the moonraker.conf”<\/p>\n\n\n\n

I looked at moonraker.conf to check the address, and then I exec’d into the klipper and moonraker containers to make sure they could both see the klipper socket. I did a “touch” on a file from one container and could see it in the other container. <\/p>\n\n\n\n

I finally started digging around in the docker volumes and figured out I had two volumes in an odd state:<\/p>\n\n\n\n

prind3_log<\/p>\n\n\n\n

prind3_run (this is the one that contains the klipper socket)<\/p>\n\n\n\n

Sidebar here: I had this problem a few months ago and fixed it by reinstalling prind. I ended up reinstalling it in a folder called “prind3” and I was completely flummoxed that the new installation stopped working if I renamed it back to the original “prind” folder name<\/em>. As you can see, the volume name format is <prind folder>_<container name>. So when I renamed the working installation back to “prind”, it stopped working because it went back to using these broken volumes. <\/p>\n\n\n\n

I was not able to delete the volumes using docker volume rm <volume name><\/code>–I got an error about it being used by an active container (LIES!)<\/p>\n\n\n\n

I was able to delete the volumes from the file system by removing the folders (as root) under:<\/p>\n\n\n\n

\/var\/lib\/docker\/volumes<\/p>\n\n\n\n

However they still showed up when I ran docker ls<\/code>. I ended up having stop all the container with docker-compose, and then restart the docker service. At this point the phantom volumes were gone, and when I started up Prind everything was working. <\/p>\n\n\n\n

This stackoverflow post<\/a> helped steer me in the right direction for how to remove the phantom volumes. The way I found the phantom volumes was by running:<\/p>\n\n\n\n

docker volume rm $(docker volume ls -q --filter dangling=true)<\/code><\/p>\n\n\n\n

followed by:<\/p>\n\n\n\n

docker volume ls -q --filter dangling=true<\/code><\/p>\n\n\n\n

Which showed a couple remaining volumes, which as I mentioned earlier I wasn’t able to remove without extraordinary measures. There was one casualty here–since prind was not running it clobbered the volume that stored all the gcode files I had uploaded to Moonraker. Not really a loss in my case. <\/p>\n","protected":false},"excerpt":{"rendered":"

I use prind to run my 3d printer. I’ve had this happen twice now where I get this error after an unexpected shutdown (like a power outage): “Moonraker can’t connect to Klipper! Please check if the Klipper service is running and klippy_uds_address is correctly configured in the moonraker.conf” I looked at moonraker.conf to check the … <\/p>\n

Continue reading “Prind Broken After Unexpected Shutdown”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/posts\/631"}],"collection":[{"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/comments?post=631"}],"version-history":[{"count":1,"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/posts\/631\/revisions"}],"predecessor-version":[{"id":632,"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/posts\/631\/revisions\/632"}],"wp:attachment":[{"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/media?parent=631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/categories?post=631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mattjm.com\/blog\/wp-json\/wp\/v2\/tags?post=631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}