1
0
mirror of git://sourceware.org/git/lvm2.git synced 2025-01-03 05:18:29 +03:00
Commit Graph

7 Commits

Author SHA1 Message Date
Tony Asleson
5392a612dc lvmdbusd: WS/pep8 corrections 2016-08-29 15:28:06 -05:00
Tony Asleson
7e37e7fde4 lvmdbusd: Always fork & exec background commands
Our background job support requires a separate instance of lvm.  Use the
full lvm command to do so.
2016-08-29 15:26:55 -05:00
Tony Asleson
20b21f4fd8 lvmdbusd: Fix hang for Job.Wait(n)
When a client is doing a wait on a job, any other clients will hang
when trying to do anything with the service.  This is caused by
the wait code which  was placing the thread that handles
incoming dbus requests to sleep until either the timeout expired or
the job operation completed.

This change creates a thread for the wait request, so that the thread
processing incoming requests can continue to run.
2016-07-28 11:13:29 -05:00
Tony Asleson
c11003c860 lvmdbusd: Remove unused imports and function parameter 2016-06-28 12:44:45 -05:00
Tony Asleson
dd5d865020 lvmdbusd: Fix hang when lvm compiled with 'enable-notify-dbus'
The following operations would hang if lvm was compiled with
'enable-notify-dbus' and the client specified -1 for the timeout:

* LV snapshot merge
* VG move
* LV move

This was caused because the implementation of these three dbus methods is
different.  Most of the dbus method calls are executed by gathering information
needed to fulfill it, placing that information on a thread safe queue and
returning.  The results later to be returned to the client with callbacks.
With this approach we can process an arbitrary number of commands without any
of them blocking other dbus commands.  However, the 3 dbus methods listed
above did not utilize this functionality because they were implemented with a
separate thread that handles the fork & exec of lvm.  This is done because these
operations can be very slow to complete.  However, because of this the lvm
command that we were waiting on is trying to call back into the dbus service to
notify it that something changed.  Because the code was blocking the process
that handles the incoming dbus activity the lvm command blocked.  We were stuck
until the client timed-out the connection, which then causes the service to
unblock and continue.  If the client did not have a timeout, we would have been
hung indefinitely.

The fix is to always utilize the worker queue on all dbus methods.  We need to
ensure that lvm is tested with 'enable-notify-dbus' enabled and disabled.
2016-06-28 12:09:28 -05:00
Tony Asleson
70d0b210e1 lvmdbusd: background.py, fix stdout parse error
It appears that the output of lvconvert --merge can vary some.  The code
was blowing up as it was trying to parse a line of stdout to retrieve the
% complete, but the line did not have the needed format and an execption
was thrown.  The uncaught exception caused the background thread to exit
without updating the job object, which caused the client to hang forever
waiting.  Added a default exception handler to prevent unhandled execptions
causing hangs and removed the parameter skip_first_line as it's no longer
needed.  The code checks to see if the line can be parsed before doing so.

Signed-off-by: Tony Asleson <tasleson@redhat.com>
2016-02-22 16:07:54 -06:00
Alasdair G Kergon
5987562cf9 lvmdbus: Add new daemon. 2016-02-17 23:53:35 +00:00