Octoprint: Empty _default.profile generated during migration [WAS: Error starting the new 1.3.3 (master branch) version]

Created on 1 Jun 2017  Â·  20Comments  Â·  Source: OctoPrint/OctoPrint

I just update to the new 1.3.3 (master branch) but just after it complete the process I was not able anymore to start Octoprint. I send my log file. If someone could help I would really appreciate since I am not an expert.

Thanks

octoprint.txt

I have read the FAQ.

bug triage unreproduced

Most helpful comment

Wasn't meant as a specific complaint, more a general observation :)

Btw, I usually leave one week between an RC and the next version and always try to leave a full weekend in the middle, just as a rough house number of when to expect releases/new RCs.

All 20 comments

Hi @FabioMC,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-06-14 23:20 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

Had the same issue. I deleted the Serial section of my config.yaml and it seems to have fixed the issue temporarily. Seems to be an issue with reading the previous printer profile. Wiping that section seemed to have erased the profile and allowed it to continue.

This looks like something is really wrong with the default printer profile at the time of auto-connect on server startup, causing things to explode. However I have no idea HOW this happens in the first place, since I cannot for the life of me reproduce this scenario/get the printer profile to break such that this error can even trigger.

@FabioMC @johnrosenbaum Could you please provide me with your config.yaml or at least its printerProfile subsection, and .octoprint/printerProfiles/_default.profile files? Just send them to [email protected] please. No need to post them publicly here since at least config.yaml might also contain sensitive data.

Had the same issue also, but in my case there appears to be no default profile, or any profiles for that matter. The _default.profile file is blank and the profiles section of the config.yaml is just an empty hash "{}". I was able to get octoprint to start up by physically disconnecting the usb cable, but I'm unable to add new profiles via the UI.

Ah, that "empty hash" issue might be the clue to at least allow me reproduction. Thank you for that.

In the meantime I've set the release to "pre release" status, that should at least stop the rollout until a hotfix is ready.

Ok, I now at least have a reproduction. What I still don't understand is why _default.profile becomes an empty file in the first place, because it should either be the hard coded default profile or whatever you had previously in config.yaml. I've tried to get it to write an empty file by manipulating the config.yaml value and running the migration but so far all I get are perfectly valid files.

Any details on how you had your printer profile setup initially (if at all) might help here.

@brentmc79 could you send me your empty _default.profile? It might be important to know whether it is indeed completely empty or if there is some whitespace in there.

@foosel just sent you an email with the file zipped up since gmail wouldn't let me attach a 0 byte file

Thanks, got it. So it really is completely empty. Huh. I have no idea how that could happen. Will try some more to reproduce this particular scenario, but if I don't find that until noon I guess I'll just go with pushing a patch (either as 1.3.3post1 or 1.3.4, not sure yet) that at least solves the crashing issue and fixes the _default.profile if it becomes invalid like this.

@brentmc79 quick questions, what creation and modification dates does the empty profile have on the file system? Not sure if the date it shows me in the zipped version is accurate or not.

pi@octocake:~/.octoprint/printerProfiles $ stat _default.profile 
  File: ‘_default.profile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: b302h/45826d    Inode: 44265       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      pi)   Gid: ( 1000/      pi)
Access: 2017-06-01 03:14:39.634282687 +0000
Modify: 2017-06-01 03:14:39.644282618 +0000
Change: 2017-06-01 03:14:39.644282618 +0000
 Birth: -

Thank you. That pretty much rules out the idea I had while stepping through various versions of past code that it might have been caused by an old _default.profile still lying around. So that idea was a dead end, which is both a relief and a curse ;)

is printerProfiles: {} incorrect? That is how my config.yaml reads. I don't use auto connect and I haven't experienced any problems. I do have one profile named Prusa configured. _default.profile exists and appears to be fully formed.

printerProfiles: {} is fine. But something like

printerProfiles:
  defaultProfile: null

wouldn't be.

I just released 1.3.4 with a fix for the crashing issue caused by the corrupted profile. I still have not found any way to reproduce it becoming blank. Now I'm a bit unsure what to do about this ticket, since the core reason of the problems is not fixed, only the symptoms are made less severe.

Ah, before I forget:

What to do if you are affected by this and your OctoPrint server isn't starting up anymore

  • Unplug your printer from your OctoPrint server (e.g. your Pi)
  • Restart your server, it should now actually start through
  • Update to 1.3.4 (if you do not get the notification that the update is available, go to Settings > Software Update > Advanced Options, click the button that says "Force check for update").
  • Plug your printer back in, all should be working fine now again.

Just a related note - 1.3.3 started up for me, but when I tried to print, I received the warning that my print was outside the bounds of the print area. I noticed that my previously selected printer was no longer selected. Once I re-selected my printer, all was OK with 1.3.3.

(I see now that you've already addressed this elsewhere).

Yeah, that's tracked in #1943. Sadly did notice that bug only just right after I'd pushed out 1.3.4 (as in, less than 5 minutes after) so now that will have to wait until 1.3.5. Bloody typos ;)

All I can say is, we apparently still need more people testing the release candidates ^^

All I can say is, we apparently still need more people testing the release candidates ^^

Sorry about that. I had loaded the RCs for 1.3.3 to my Raspberry Pi , but never got as far as connecting to my printer before the released version came out :(

Wasn't meant as a specific complaint, more a general observation :)

Btw, I usually leave one week between an RC and the next version and always try to leave a full weekend in the middle, just as a rough house number of when to expect releases/new RCs.

I just released 1.3.4 with a fix for the crashing issue caused by the corrupted profile. I still have not found any way to reproduce it becoming blank. Now I'm a bit unsure what to do about this ticket, since the core reason of the problems is not fixed, only the symptoms are made less severe.

Decided to close it since I also haven't heard anything about it anymore.

Was this page helpful?
0 / 5 - 0 ratings