Description of problem: Incorrect permissions against /tmp can result in looping OvfWriter failures as we attempt to end the task (BZ#984491) : 2013-07-06 21:06:15,423 ERROR [org.ovirt.engine.core.bll.EntityAsyncTask] (pool-3-thread-49) EntityAsyncTask::EndCommandAction [within thread]: EndAction for action type ImportVm threw an exception: org.ovirt.engine.core.compat.CompatException: java.io.IOException: Permission denied at org.ovirt.engine.core.compat.backendcompat.Path.GetTempFileName(Path.java:23) [engine-compat.jar:] at org.ovirt.engine.core.utils.ovf.OvfWriter.<init>(OvfWriter.java:34) [engine-utils.jar:] at org.ovirt.engine.core.utils.ovf.OvfVmWriter.<init>(OvfVmWriter.java:27) [engine-utils.jar:] at org.ovirt.engine.core.utils.ovf.OvfManager.ExportVm(OvfManager.java:22) [engine-utils.jar:] at org.ovirt.engine.core.bll.VmCommand.UpdateVmInSpm(VmCommand.java:182) [engine-bll.jar:] at org.ovirt.engine.core.bll.VmCommand.UpdateVmInSpm(VmCommand.java:156) [engine-bll.jar:] at org.ovirt.engine.core.bll.ImportVmCommand.UpdateVmImSpm(ImportVmCommand.java:984) [engine-bll.jar:] at org.ovirt.engine.core.bll.ImportVmCommand.endVmRelatedOps(ImportVmCommand.java:974) [engine-bll.jar:] at org.ovirt.engine.core.bll.ImportVmCommand.EndImportCommand(ImportVmCommand.java:965) [engine-bll.jar:] at org.ovirt.engine.core.bll.ImportVmCommand.endSuccessfully(ImportVmCommand.java:924) [engine-bll.jar:] at org.ovirt.engine.core.bll.CommandBase.internalEndSuccessfully(CommandBase.java:512) [engine-bll.jar:] at org.ovirt.engine.core.bll.CommandBase.endActionInTransactionScope(CommandBase.java:459) [engine-bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1374) [engine-bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:204) [engine-utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInRequired(TransactionSupport.java:142) [engine-utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:109) [engine-utils.jar:] at org.ovirt.engine.core.bll.CommandBase.endAction(CommandBase.java:405) [engine-bll.jar:] at org.ovirt.engine.core.bll.Backend.endAction(Backend.java:369) [engine-bll.jar:] While the exception is valid should we try to use another location if /tmp is not accessible like this? Version-Release number of selected component (if applicable): rhevm-3.1.0-50.el6ev.noarch Sun 24 Mar 2013 08:42:37 PM GMT rhevm-backend-3.1.0-50.el6ev.noarch Sun 24 Mar 2013 08:42:30 PM GMT How reproducible: Always Steps to Reproduce: 1. Break /tmp permissions with chmod 1770 etc. 2. Try to import/export, edit the guest in some way that will result in OVF modification etc. 3. Task will loop attempting to end successfully. Actual results: OvfWriter fails due to /tmp permission issues. Expected results: OvfWriter attempts to use another scratch space before failing. Additional info:
Lee, why do you think it is valid for /tmp to have non standard permissions? Do you think that ovirt-engine is the only application that will break in this mode? Based on POSIX[1]: --- The following directory shall exist on conforming systems and shall be used as described: /tmp A directory made available for applications that need a place to create temporary files. Applications shall be allowed to create files in this directory, but shall not assume that such files are preserved between invocations of the application. --- But let's say /tmp is not writable... why do you think that any other place application will assume that is writable will be writable and not modified by sysadmin? Anyway, as a solution you can add -Djava.io.tmpdir=<whatever> to redirect jvm temp directory, example: /etc/ovirt-engine/engine.conf.d/50-tmpdir.conf --- ENGINE_PROPERTIES="-Djava.io.tmpdir=/var/tmp" --- [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html
(In reply to Alon Bar-Lev from comment #1) > Lee, why do you think it is valid for /tmp to have non standard permissions? > Do you think that ovirt-engine is the only application that will break in > this mode? I don't think it is valid for /tmp to have non standard permissions and obviously other applications may suffer if they have been changed. However at present this results in a non intuitive task failure error in the UI and in some cases a looping task that continuously fails (BZ#984491). If you feel that attempting to switch to a location already used by engine (ie. /var/tmp/ovirt-engine) isn't valid then we should at least improve the exception being thrown and the error displayed in the UI. Thanks, Lee
(In reply to Lee Yarwood from comment #2) > If you feel that attempting to switch to a location already used by engine > (ie. /var/tmp/ovirt-engine) isn't valid then we should at least improve the > exception being thrown and the error displayed in the UI. I think I can make the process do all sort of strange behaviors regadless the safeguards. But I agree that command should fail and not loop.
fixing the loop should be enough, see bug 984491 *** This bug has been marked as a duplicate of bug 984491 ***