GUI restore starts multiple tasks

[hk@]

Hi,
I tested this serveral times, it doesn't appear to happen always, but if I do have to restore a large backup-file (tar.lzo) - roughly 30 GB - it happens that I press the restore button after selecting the file and choosing "restore" as an action and then assigning a new local PVE-ID, the window remains open and I press restore for another time (as I thought I hadn't pressed it correctly) and then a third time, then all of a sudden three restore-processes run in parallel and hit each other with locks and errors...

Please integrate some locking for this not to happen.

Kindest Regards
hk

 

[dietmar]

then all of a sudden three restore-processes run in parallel and hit each other with locks and errors...

Please integrate some locking for this not to happen.

Locking is implemented on the server side - that is why you got the errors. So one of those task should succeed - or does all tasks fail?

 

[dietmar]

the window remains open and I press restore for another time

Strange, I am unable to reproduce that. The window always closes here.

 

[hk@]

nope,
two tasks were restoring in parallel and the third one got locked out. if there were a way to get the task history beyond the now viewed tasks in the proxmox gui I probably could give you the logs of both processes jeopardizing each other.

You probably need a server that at restore goes up to loads like 70 and is really cornered in to see this (or probably some really slow connectivity from the client to the server) - but I think simply locking the "restore" button after it has been pressed once in the javascript would help prevent this.

regards
hk

 

[dietmar]

if there were a way to get the task history beyond the now viewed tasks in the proxmox gui I probably could give you the logs of both processes jeopardizing each other.

Please select the node and use the 'Task History' item - all tasks should be there.

 

[hk@]

ups - thanks for the pointer!

the three tasks in question responded this:

a)
TASK ERROR: unable to create CT 1108 - directory '/var/lib/vz/private/1108' already exists

b)
extracting archive '/mnt/pve/backup/dump/vzdump-openvz-1108-2012_03_18-00_11_04.tar.lzo'
tar: ./home/live/web/img/be/7475__image.jpg: Cannot change ownership to uid 33, gid 33: No such file or directory
tar: ./home/live/web/img/be/4345__Gra.rar: Cannot utime: No such file or directory
tar: ./home/live/web/img/db/thumbs/1620_minithumb.jpg: Cannot change ownership to uid 33, gid 33: No such file or directory
tar: ./home/live/web/img/db/thumbs/2794.jpg: Cannot change ownership to uid 33, gid 33: No such file or directory

c)
extracting archive '/mnt/pve/backup/dump/vzdump-openvz-1108-2012_03_18-00_11_04.tar.lzo'
tar: ./usr/share/ImageMagick-6.2.4/config/magic.xml: Cannot utime: No such file or directory
tar: ./home/live/web/img/be/3489.jpg: Cannot utime: No such file or directory
tar: ./home/live/web/img/db/thumbs/10778.jpg: Cannot utime: No such file or directory
tar: ./home/live/web/img/db/thumbs/10778.jpg: Cannot change ownership to uid 33, gid 33: No such file or directory


I then intervened and killed the restore tasks as root - here I'd suggest a button or something to stop a running task

regards
hk

 

[dietmar]

the three tasks in question responded this:

And task b and c restores to the same VMID?

 

[hk@]

exactly that I selected the backup file chose "restore" and entered the VEID 1108 - then pressed three times restore and that was what happened...

 

[tom]

see https://bugzilla.proxmox.com/show_bug.cgi?id=43

 

[hk@]

I agree, but this happened to me because the GUI was slow to respond, I did not intentionally restore the same backup into the same VEID, therefore I opt for some kind of locking here (simply disable the restore button after it has been clicked could suffice).
Also I'd consider two admins working in parallel - even if they choose (intentional or by accident) the same VEID to restore it would be nice not to have this problem.
regards, hk

 

[tom]

yes, that is the idea.