https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-12195 Lustre <p>this is because the test rely on binaries running/copied from lustre/tests (like multiop).<br/> but they aren't binary anymore - they are libtool-based scripts.<br/> I have to rollback the change to enable local testing:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> --- a/lustre/tests/Makefile.am +++ b/lustre/tests/Makefile.am @@ -1,6 +1,7 @@ # Lustre test Makefile AM_CFLAGS := -fPIC -D_GNU_SOURCE \ -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 +AM_LDFLAGS := -no-install </pre> </div></div> LU-12195

sanity/43 and sanityn/14 fail on local setups

Bug Minor Resolved Fixed James A Simmons Alex Zhuravlev Thu, 18 Apr 2019 15:25:55 +0000 Thu, 4 Jun 2020 05:19:28 +0000 Tue, 30 Apr 2019 13:09:40 +0000 Lustre 2.13.0 Lustre 2.12.3 0 5 <p>It seems like for sanity/43<span class="error">&#91;ab&#93;</span> and sanityn/14<span class="error">&#91;abcd&#93;</span> it would be possible to use "<tt>sleep</tt>" instead of "<tt>multiop</tt>" as the test program, so that we can ignore the libtool issues:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> cp $(which sleep) $DIR/$tdir/sleep $DIR/$tdir/sleep 1000 &lt; $TMP/$tfile.junk &amp; PID=$! </pre> </div></div> <p>I thought some things might be missed. The issue is that packaging was broken with rpath issues which prevented some vendors from creating their own rpms.. So we had to remove the no-install flag. I create a work around to running the test local with <a href="https://jira.whamcloud.com/browse/LU-11742" title="ERROR: RPATH is not allowed" class="issue-link" data-issue-key="LU-11742"><del>LU-11742</del></a>. Sadly this requirement to run test in the source tree makes things much more complicated compared to other projects.</p> <p>what about adding no-install flag as an option with some configure option?<br/> @Andreas, I'm fine to change that to sleep, hopefully this is the only remaining issue with libtool wrapper.</p> <p>sanityn/14* seem to be duplicate of sanity/43*. would you mind if I remove sanityn/14* tests?</p> <p>Alex Zhuravlev (bzzz@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/34721" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34721</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-12195" title="sanity/43 and sanityn/14 fail on local setups" class="issue-link" data-issue-key="LU-12195"><del>LU-12195</del></a> tests: use sleep instead of wrapped multiop<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 82c898be49c73d983e910a2e184d5d0f5c8d6222</p> <p>Sanity is usually for testing cross-client operations, and as you probably saw, it is checking if the binary can be removed or truncated from a second mountpoint. </p> <p>sanity: FAIL: test_118c Multiop failed to block on fsync, pid=9583<br/> sanity: FAIL: test_118d Multiop failed to block on fsync, pid=9876</p> <p>for the same reason..</p> <p>and I grepped sanity:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"></pre> </div></div> <p>$ grep 'MULTIOP.*<span class="error">&#91;&amp;&#93;</span>' lustre/tests/sanity.sh|wc -l<br/> 23<br/> {code]</p> <p>still wondering would it make sense to disable wrapping with some configure option?</p> <p>The point of the libtool wrappers around the applications is to work with installed and uninstalled libraries. So when the rpm is installed running libtool with the application will see its a properly installed binary and look in the normal paths for the applications libraries. If working in the sandbox lustre/test/* then the libtool wrapper will properly select the uninstalled libraries in lustre/test/*/.lib. This is nice in that this ensures that if you do test out of sand box that the sandbox version of library is used instead of the installed one. Yes I have used this trick to debug. The trade off is that your working with the wrapper and not the binary directly so running things like pkill on the wrapper will not work.</p> <p>Normally projects that want do a sand box mode do a make DESTDIR which creates a kind of chroot environment to work in. Sadly this is not the case for Lustre which just wants to work directly in the source tree. So it makes it much more difficult to make this transparent. The source tree layout doesn't match the DESTDIR tree layout. The other option often done for sandbox mode is running ./configure --prefix=/path/to/sandbox and doing a make install. The issue still ends up being where do the binaries and libraries go. Again the source tree also doesn't match the final tree structure. The test framework would have to be reworked to setup the library paths and run ldconfig. Its also a change that the developer has to be aware of. Also we have to be careful with library collisions since a properly installed version could be installed as well. Without using the libtool wrapper that is not guaranteed the proper library would be used.</p> <p>The last item is when wanting to run in sandbox mode is to run ./configure --disable-shared. This avoids the whole where are the libraries and applications problem. Now the issue is the libtool wrapper still exist so doing a song and dance would be required to make it work. Requiring using the --disable-shared is of course not so transparent to the developer so you have to ask do you want to go down that road. Perhaps in that case we make disabled-shared enabled by default and then in the rpm part pass in enable-shared to configure. Then of course what do we do when enable-shared is done in sand box which would break things. The challenge again is making the test suite work with both proper installed test suite and in sandbox transparently.</p> <p>As you can see their is no easy solution so I picked the lesser of all evils. Using libtool execute mode. Just throwing things out their to think about what the options entail.</p> <p>I'm fine with --disable-shared as 1) configure is not very frequent procedure 2) I almost never type arguments for configure using command history instead.<br/> for me the issue is that I can not run sanity anymore. yes, I can disable few dozen tests, but I don't think this is a good idea.</p> <p>--disable-shared (after make clean) did the trick and I got binaries back.</p> <p>Alright. I will look into making this the default when not building rpms.</p> <p><a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=simmonsja" class="user-hover" rel="simmonsja">simmonsja</a> thanks in advance, but to be clear - --disable-shared worked for me and this is pretty much enough, I have no problem adding this option to configure args. not that I'm against making this default, but I guess you've got more interesting problems <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/34721/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34721/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-12195" title="sanity/43 and sanityn/14 fail on local setups" class="issue-link" data-issue-key="LU-12195"><del>LU-12195</del></a> tests: use sleep instead of wrapped multiop<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 9a1f327a76f72c7713e53d8b354ff7f0e32be870</p> <p>Landed for 2.13</p> <p>James Simmons (uja.ornl@yahoo.com) uploaded a new patch: <a href="https://review.whamcloud.com/34955" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34955</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-12195" title="sanity/43 and sanityn/14 fail on local setups" class="issue-link" data-issue-key="LU-12195"><del>LU-12195</del></a> tests: use sleep instead of wrapped multiop<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: 2a1cdc610fc3146b9cc96f6b8bc1826d36d6d764</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/34955/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34955/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-12195" title="sanity/43 and sanityn/14 fail on local setups" class="issue-link" data-issue-key="LU-12195"><del>LU-12195</del></a> tests: use sleep instead of wrapped multiop<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: <br/> Commit: 493ce6e49de3a9de82d5fe9fc8d7b5d9a78c68c2</p> Duplicate LU-12170 Related LU-11742 LU-12261 Development Rank 1|i00f13: Rank (Obsolete) 9223372036854775807 Severity