|author||Joey Hess||2017-09-01 18:45:31 -0400|
|committer||Joey Hess||2017-09-01 18:45:31 -0400|
Diffstat (limited to 'doc')
1 files changed, 25 insertions, 0 deletions
diff --git a/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_3_1405e20c8f5dc6e9cca3732e3e368d03._comment b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_3_1405e20c8f5dc6e9cca3732e3e368d03._comment
new file mode 100644
@@ -0,0 +1,25 @@
+ subject="""comment 3"""
+One way would be to use System.Process's `close_fds` when executing
+vgs/lvs. BTW, I've seen such complaints from lvm before, in some
+situations not involving propellor.
+I've made a commit that makes the propellor lock FD be close-on-exec,
+which is generally a good idea for lock FDs anyway. (To prevent some
+long-running daemon process that does not close such FDs keeping the lock
+My guess is that the other 4 FDs, which are apparently pairs of FDs
+at both sides of a pipe, come from
+System.Console.Concurrent.Internal.bgProcess, which sets up just such a
+pipe. Quite possibly when vgs/lvs are run, it's via that function.
+Generally leaking non-lock-related FDs to child processes is not a big
+problem, as long as the child process doesn't write to random FDs (which
+would be pretty bad, but what would ever do that?) ... So I don't know if I
+want to try to chase down every FD used all through propellor to set them