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-5454 Lustre <p>The /etc/init.d/lnet script should be supported on SLES machines. Currently, the lnet init script is only packaged when building for a RHEL distribution. It should be pretty straightforward to support the lnet init script on SLES as well. As far as I can tell, it doesn't do anything necessarily RHEL-specific.</p> LU-5454

Support lnet init script on SLES

Improvement Minor Open Unresolved WC Triage Ryan Haasken Tue, 5 Aug 2014 22:13:46 +0000 Wed, 6 Aug 2014 21:39:34 +0000 1 5 <p>This is related to <a href="https://jira.whamcloud.com/browse/LU-4707" title="Don’t deploy the “lustre” init script on clients" class="issue-link" data-issue-key="LU-4707"><del>LU-4707</del></a> since the change that fixed that bug stopped the packaging of /etc/init.d/lnet on SLES.</p> <p>I don't think your description is at all accurate. I see a bunch of things in the lnet script as it exists now that are very RHEL specific.</p> <p>In addition to those I believe in SLES rc scripts there are quite rigid conventions about comment headers in rc scripts that help specify dependencies and order of execution. Pretty sure the existing script doesn't conform at all. Would probably need a more SLES specific script and Makefile support to package the right ones for each distro. Or maybe that's one possible approach.</p> <p>I believe our policy on scripts was always to describe ours as examples and recommend users wanting to use them customize them as necessary in whatever site specific way was needed. I could be wrong, but that is my impression.</p> <p>Hi Bob.</p> <p>I've done some further investigation to figure out just how RHEL specific the current lnet init script is.</p> <p>This section at the beginning of the script sources two RHEL-specific files:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"># Source function library. [ -f /etc/rc.d/init.d/functions ] &amp;&amp; . /etc/rc.d/init.d/functions # Source networking configuration and check that networking is up. [ -f /etc/sysconfig/network ] &amp;&amp; . /etc/sysconfig/network &amp;&amp; \ [ <span class="code-quote">"${NETWORKING}"</span> = <span class="code-quote">"no"</span> ] &amp;&amp; exit 0 </pre> </div></div> <p>For /etc/rc.d/init.d/functions, there is a similar SLES alternative, /etc/rc.status. However, as far as I can tell, nothing from /etc/rc.d/init.d/functions is being used by the lnet script anyway. Am I missing something?</p> <p>For /etc/sysconfig/network, there is apparently no SUSE equivalent. I'm not sure how to address that. We could probably ignore that check on whether NETWORKING is enabled.</p> <p>Another compatibility issue is the use of the file /var/lock/subsys/lnet. Here is what SUSE says about /var/lock/subsys (source: <a href="http://en.opensuse.org/openSUSE:Packaging_checks" class="external-link" target="_blank" rel="nofollow noopener">http://en.opensuse.org/openSUSE:Packaging_checks</a> ):</p> <blockquote> <p>/var/lock/subsys is neither used nor supported on openSUSE. Other distributions use it to mark that an init script has run. There is no equivalent on openSUSE. So in most cases refereces to /var/lock/subsys can be removed without replacement.</p></blockquote> <p>Since there is no SUSE equivalent, we'll just remove that for SLES.</p> <p>With respect to the rigid conventions about comment headers in rc scripts, I don't believe those conventions are specific to SLES. I think it is an LSB thing. See the description here: <a href="https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html" class="external-link" target="_blank" rel="nofollow noopener">https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html</a></p> <p>I think this means it would be okay, and even desirable, to include such a comment header in the init script for RHEL <b>and</b> SLES.</p> <p>I can see a couple of ways to achieve lnet init script support for SLES. One would be to create two init scripts like you suggested, one for each distro. However, we could also do something like this and use just a single init script for both:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">if</span> [ -f /etc/rc.d/init.d/functions ] ; then # define RHEL-specific {start,stop,...} functions elif [ -f /etc/rc.status ]; then # define SLES-specific {start,stop,...} functions fi </pre> </div></div> <p>That's probably the way I would prefer to proceed. Do you have any thoughts on this plan? Did I miss anything that's RHEL specific in the LNET init script?</p> <p>I should also address this comment:</p> <blockquote> <p>I believe our policy on scripts was always to describe ours as examples and recommend users wanting to use them customize them as necessary in whatever site specific way was needed. I could be wrong, but that is my impression.</p></blockquote> <p>We would like an LNet init script for our usage on SLES nodes. There's not really anything site-specific about this lnet init script, so as long as I'm creating one that works for us, I'd like to contribute that change here.</p> <p>Ryan,<br/> I don't object in principle to you taking on the effort to craft truly general lnet &amp; lustre init scripts. I think you've identified all the major areas that might be RHEL or SLES specific. I just worry that the rc.status include in SLES &amp; functions include in RHEL might not be exactly equivalent in the primitives they provide to rc scripts. I also don't know in detail all the functions or global definitions used. I also don't know how much is provided by the /etc/sysconfig/network script in RHEL. It may be required for more than just ensuring that networking is already running. I agree it has no exact equivalent in SUSE, where /etc/sysconfig/network is a directory and not a script.</p> <p>As far as I know you have called out the major diffs between SLES &amp; RHEL rc frameworks that have an impact.</p> <p>I would hope that whatever you do would be tested sufficiently in both SUSE &amp; RHEL that it doesn't add noise in terms of extra warnings or errors at install time or boot time.</p> <p>Do you plan to confine your efforts to just the lnet init script or take on the lustre one too? I think they are packaged together.</p> <p>That's correct. The functions provided by RHEL in /etc/rc.d/init.d/functions are not the same as the functions provided by SLES in /etc/rc.status. However, I looked closely, and I don't see anything in /etc/init.d/lnet that uses any of those functions, so I'm not too worried about that. </p> <p>The only thing the lnet init script uses out of /etc/sysconfig/network is the variable NETWORKING for this check:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"># Source networking configuration and check that networking is up. [ -f /etc/sysconfig/network ] &amp;&amp; . /etc/sysconfig/network &amp;&amp; \ [ <span class="code-quote">"${NETWORKING}"</span> = <span class="code-quote">"no"</span> ] &amp;&amp; exit 0 </pre> </div></div> <p>Yes, I'll test it on both a CentOS and a SLES machine and check for error messages.</p> <p>We only have a need for the lnet init script, and the lustre one is massive, so I'd prefer not to get into that. Yes, they are packaged together based on the value of the automake conditional INIT_SCRIPTS:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">if</span> INIT_SCRIPTS initdir = $(sysconfdir)/init.d init_SCRIPTS = lnet <span class="code-keyword">if</span> SERVER init_SCRIPTS += lustre endif endif </pre> </div></div> <p>I could change it so that the lnet init script is packaged separately, so I can avoid making the lustre init script compatible with SLES.</p> <p>I did a quick scan of the lustre init script, and it actually looks like very little is dependent on RHEL-specific functionality. It sources /etc/rc.d/init.d/functions, but it doesn't look like it uses anything from that file. It also sources /etc/sysconfig/network, and it uses the NETWORKING definition to see if networking is enabled. It does not actually touch any files under /var/lock/subsys, so no work would need to be done there.</p> <p>We don't use the lustre init script, so I'm not sure how to use it and test it. We also don't run Lustre servers on SLES, so I would have to figure out how to test that. I'd prefer to just port the lnet init script to SLES, but the lustre init script could potentially be ported if necessary.</p> Development Rank 1|hzwt0n: Rank (Obsolete) 15188