| Summary: | sys-fs/lvm2-2.02.110 - /etc/init.d/lvm should not set "need lvmetad" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jaco Kroon <jaco> |
| Component: | [OLD] Core system | Assignee: | Robin Johnson <robbat2> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | agk, ahferroin7, aidecoe, cardoe, dmoulding, henson, rossi.f, sebastian, ulf.norberg, whissi |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Seconded. lvmetad should not be started unconditionally.I don't think it should even be a separate init script, it's part of lvm. /etc/init.d/lvm should start it itself if lvm.conf sets use_lvmetad to true.What would be the use case for running lvmetad and not lvm? To prevent lvematd from starting, add the following to /etc/conf.d/lvm rc_lvm_provide="lvmetad" Source: https://forums.gentoo.org/viewtopic-p-7697058.html#7697058 (In reply to BT from comment #2) > To prevent lvematd from starting, add the following to /etc/conf.d/lvm > > rc_lvm_provide="lvmetad" > > Source: https://forums.gentoo.org/viewtopic-p-7697058.html#7697058 I personally don't feel that that is a clean solution. It'll work but it also implies that if you want (or don't want) to use lvmetad you need to update the config in multiple places. That is not ideal but it does give me a way of updating /etc/conf.d/lvm to conditionally deal with it by adding the following line: needlvmetad="$(exec 3<&-; /sbin/lvm dumpconfig global | sed -nre 's/^[[:space:]]*use_lvmetad=//p')" [ "${needlvmetad}" -eq 0 ] && rc_lvm_provide="lvmetad" unset needlvmetad I still think however the best solution is to update /etc/init.d/lvm to correctly deal with the situation. Is there any way to ask openrc to recalc dependencies if /etc/lvm/lvm.conf changed? Re-seconded (thirded?). I also agree with Paul B. Henson that lvmetad probably shouldn't exist as a separate init script. Keeping it all in one init script would avoid all complexities that arise from having a dynamic dependency. Personally I don't care about whether or not it's a separate init script. That said, I do think it shouldn't default to a hard dependency,as:
1. LVM is supposed to be started as early as possible in the boot runlevel. lvmetad can't be started until after when LVM is supposed to be started.
2. lvmetad is potentially dangerous to run on non-server grade hardware, because a single memory error can cause it's cached metadata to become corrupted, which has the potential to completely nuke your VG's
3. lvmetad's primary purpose is to avoid disk accesses. This is only really worth considering for:
a. Pathologically stupid management software
b. Near-line storage arrays
c. HPC systems
d. People who are being extremely aggressive with power efficiency
And none of those are common cases for the average Gentoo user.
At the very least, we need to get the init script for lvmetad fixed so that it works when it gets started before localmount.
Oh, and bugs #565154, #554918, #503016 all directly complain about this, #500732 is a direct complaint about issues caused by lvmetad, and #521960 is a specific complaint about the issue I mentioned above about starting lvmetad when LVM is needed during boot. Clearly, this is causing issues for users. *** Bug 554918 has been marked as a duplicate of this bug. *** *** Bug 565154 has been marked as a duplicate of this bug. *** *** Bug 503016 has been marked as a duplicate of this bug. *** Perhaps a solution to this could be to intruduce a new USE-flag to sys-fs/lvm2, to make it optional to install lvmetad (see bug 565154). LVM2 can be configured with "--disable-lvmetad" so the lvmetad daemon will not be built at all. just in case 116-r3 ebuild updates, which claiming lvmetad need service fixed, didn't fix in reality. update to 116-r3, assuming that lvm2 and lvmetad services stopped, then run rc, and lvmetad is still started. InGit ef66b97c3c1778c3c8e9f96d80057ad7a1a3e2f4 I can confirm comment #12 that lvm2-2.02.116-r3 has not fixed this issue. I believe I found the issue with lvm2-2.02.116-r3. In commit ef66b97c3c1778c3c8e9f96d80057ad7a1a3e2f4 which makes lvm conditionally depend on lvmetad, 'need' has been hard coded to 'lvmetad sysfs' in lvm.rc-2.02.116-r3. So regardless of what 'use_lvmetad' is set to, lvm will always depend lvmetad. After removing 'lvmetad' from 'need' in depend(), lvm.rc-2.02.116-r3 now conditionally depends on lvmetad as intended. In order to test all situations I enabled lvmetad with 'use_lvmetad = 1', but lvmetad fails to start: * Setting up the Logical Volume Manager ... /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. WARNING: Failed to connect to lvmetad. Falling back to internal scanning. This might be related to commit 1d828236d11580a7fc057ff700b86e09e94cc188 which fixed the missing the missing /run/lvm directory for lvmetad. In my case /run/lvm exist but it is empty. Thanks for the report. Fixed in http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef66b97c3c1778c3c8e9f96d80057ad7a1a3e2f4 (In reply to Doug Goldstein from comment #16) > Thanks for the report. Fixed in > http://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=ef66b97c3c1778c3c8e9f96d80057ad7a1a3e2f4 Unless you have linked to the wrong commit, the issue is _not_ fixed. Please see comment #15. (In reply to BT from comment #15) > I believe I found the issue with lvm2-2.02.116-r3. In commit > ef66b97c3c1778c3c8e9f96d80057ad7a1a3e2f4 which makes lvm conditionally > depend on lvmetad, 'need' has been hard coded to 'lvmetad sysfs' in > lvm.rc-2.02.116-r3. So regardless of what 'use_lvmetad' is set to, lvm will > always depend lvmetad. > > After removing 'lvmetad' from 'need' in depend(), lvm.rc-2.02.116-r3 now > conditionally depends on lvmetad as intended. > > In order to test all situations I enabled lvmetad with 'use_lvmetad = 1', > but lvmetad fails to start: > > * Setting up the Logical Volume Manager ... > /run/lvm/lvmetad.socket: connect failed: No such file or directory > WARNING: Failed to connect to lvmetad. Falling back to internal scanning. > WARNING: Failed to connect to lvmetad. Falling back to internal scanning. > > This might be related to commit 1d828236d11580a7fc057ff700b86e09e94cc188 > which fixed the missing the missing /run/lvm directory for lvmetad. In my > case /run/lvm exist but it is empty. So you are correct, I left the extra "lvmetad" in the need statement. However with it removed you will get this error for the 1st reboot after a change and then all will be well. For some reason OpenRC is not recalculating its dependencies like its suppose to with the "config" directive. Thanks for the report. Fixed in http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f5a9734bbb67f004930c8bf8e03ad5e61a4c2d7f |
In /etc/init.d/lvm there is this line: need lvmetad sysfs This indicates that lvmetad should always be started. This isn't true, and if use_lvmetad=0 then it actually causes lvm2 commands to issue warnings. I couldn't get lvmetad to work sensibly yet and setting use_lvmetad=1 causes other issues for me. So I changed the depend() function to contain this line: local needlvmetad="$(/sbin/lvm dumpconfig global | sed -nre 's/^[[:space:]]*use_lvmetad=//p')" And to only "need" lvmetad if this value ends up being something other than 0. [ "${needlvmetad}" -eq 0 ] || need lvmetad I'm not convinced this is the best or even the "right" way, but it does work, except for: greyscale ~ # rc-update -u * Caching service dependencies ... File descriptor 3 (pipe:[223391]) leaked on lvm invocation. Parent PID 15038: /bin/sh [ ok ] greyscale ~ # Not sure how to get rid of that problem, so it still needs some work, perhaps someone else knows how to deal with that in the right manner. Reproducible: Always