Hi.
I found a strange thing.
If you run lxc snapshot CT and it failed(or interrupted) info about this snapshot will be shown in info.
It shouldn’t be like this. I think snapshot record should be added only after successful snapshot, not just after it was started.
The lxc CLI is interacting with LXD over a REST API.
When you run lxc snapshot the relevant REST API call is made to the server, the server will then create the snapshot and tell the client when done. When you hit ctrl+c all that happened is you killed the client tool but that didn’t cancel anything on the server side and the snapshot will still get created.
Some operations can be interrupted (like those downloading files) but snapshot creation isn’t one of those.
The initial post got me interested in snapshot failures (better to know the worse before it happens in real life as it inevitably happen one day, I have never a snapshot failing but I know it will happen at the most inconvenient moment), so I simulated it.
I did to the lxd server something that should NOT ever done in production (it was not) and indeed the snapshot creation crashed (obviously). Afterward (the lxd server restarted all by itself) I tried a lxc snapshot container restore and it duly failed, so my nasty trick worked, the container was marked as having a valid snapshot done and it was not.
I don’t think it’s a big deal myself, actually.
I did a lxc delete container/snapshot and the container was as good as new, no harm.
Note that my snapshot crashing was done with container stopped. I don’t know if using a snapshot with container running could change anything.
So, the question is: how can I be sure, running snapshot in script, that it was completely done?
Does $? work? I will check it myself, but want to know others opinion.
What did you do to the LXD server?
replying to both @SeventhSon and @Dnegreira
when there is an error in the handling of commands sent by lxc to lxd, lxc set the error code with the following strategy (lxc/main.go)
err = app.Execute()
if err != nil {
os.Exit(1)
so if there is an error, the lxc client returns 1 else 0
if the lxd server suffers a catastrophic problem such as a nasty admin sending it a SIGKILL signal, the end result is the same
Error: websocket: close 1006 (abnormal closure): unexpected EOF
1 <— error code
lxc list | grep test1
| test1 | STOPPED | | | PERSISTENT | 1 |
lxc restore test1 snap1
Error: Failed to run: chmod +x /var/snap/lxd/common/lxd/storage-pools/default/containers/test1: chmod: cannot access ‘/var/snap/lxd/common/lxd/storage-pools/default/containers/test1’: No such file or directory