GUI restore starts multiple tasks

H

hk@

Renowned Member
Feb 10, 2010
248
8
83
Vienna
kapper.net
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
 
hk@ said:
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.
Click to expand...

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?
 
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
 
hk@ said:
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.
Click to expand...

Please select the node and use the 'Task History' item - all tasks should be there.
 
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
 
exactly that I selected the backup file chose "restore" and entered the VEID 1108 - then pressed three times restore and that was what happened...
 
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
 
yes, that is the idea.
 
You must log in or register to reply here.
Top Bottom
Back