qubes.xml corrupted due to disk full

[zander]

Qubes OS version:

4.0RC2

Steps to reproduce the behavior:

I personally did not see this behavior, it was reported on the user mailinglist. As I realize database corruption like this is a show-stopper bug, I'm reporting it here.

https://groups.google.com/d/msg/qubes-users/svrJiQ1d7S8/zHLoTWiQBQAJ

Expected behavior:

The xml file should never be left in a corrupted state.

[blacklight447]

Ive had this too once (in qubes 3.2 admittely), but its a fairly easy fix, you just have to delete the qubes.xml and let it regenerate itself automatically. maybe we can make a script which does this by itself (removing and regenerating) once it detects a full disk?

[blacklight447]

Ive had this too once (in qubes 3.2 admittely), but its a fairly easy fix, you just have to delete the qubes.xml and let it regenerate itself automatically. maybe we can make a script which does this by itself (removing and regenerating) once it detects a full disk?

[zander]

My thinking was more in the direction that the component that generates the XML uses an atomic operation to replace the old one.
On Unix this means the xml is fully generated under a slightly different name and then (the atopic operation) renamed over the old file.

This way there is no risk of corruption.

[zander]

My thinking was more in the direction that the component that generates the XML uses an atomic operation to replace the old one.
On Unix this means the xml is fully generated under a slightly different name and then (the atopic operation) renamed over the old file.

This way there is no risk of corruption.

[tasket]

The file-saving code appears to be in qubes/app.py and it does already use the save/flush/rename method. This would mean the culprit for the error probably lies in the filesystem or thin-lvm or layers beneath.

[tasket]

The file-saving code appears to be in qubes/app.py and it does already use the save/flush/rename method. This would mean the culprit for the error probably lies in the filesystem or thin-lvm or layers beneath.

[dimlev]

I tested changing some settings using the qubes-manager (on 3.2) while my disk was full and I did not manage to corrupt qubes.xml. I did manage to corrupt firewall.xml though.

qubes/app.py uses the save/flush/rename method but qubes/firewall.py does not. So if you happen to change a firewall setting while the disk is full you end up with a zero byte / corrupted firewall.xml file.

Should I open a new issue for this?

[dimlev]

I tested changing some settings using the qubes-manager (on 3.2) while my disk was full and I did not manage to corrupt qubes.xml. I did manage to corrupt firewall.xml though.

qubes/app.py uses the save/flush/rename method but qubes/firewall.py does not. So if you happen to change a firewall setting while the disk is full you end up with a zero byte / corrupted firewall.xml file.

Should I open a new issue for this?

[dimlev]

I also tested changing vm settings on 4.0RC3 (running on virtualbox) while the disk was full. Same results with 3.2

• qubes.xml was fine.
• firewall.xml became corrupted.

Also: Patrick (in the google groups) does not mention changing any settings that would trigger saving the qubes.xml file. So if he didn't, then what are some other ways that this could happen?

[dimlev]

I also tested changing vm settings on 4.0RC3 (running on virtualbox) while the disk was full. Same results with 3.2

• qubes.xml was fine.
• firewall.xml became corrupted.

Also: Patrick (in the google groups) does not mention changing any settings that would trigger saving the qubes.xml file. So if he didn't, then what are some other ways that this could happen?