<div style="font-family: Arial; font-size: 13;">Sure, infact I can change all shebang to point to /bin/bash and it's ok.<br>The question is about current shebang /bin/sh which may go into trouble (as if one would point to a generic python but uses many specific features of a version of python).<br>Also, the question is about bash being a good option for RAs, being much more heavy.<br><br>Gabriele<br><br><div id="wt-mailcard"><div style="font-family: Arial;">----------------------------------------------------------------------------------------<br></div><div style="font-family: Arial;"><b>Sonicle S.r.l. </b>: <a href="http://www.sonicle.com/" target="_new">http://www.sonicle.com</a></div><div style="font-family: Arial;"><b>Music: </b><a href="http://www.gabrielebulfon.com/" target="_new">http://www.gabrielebulfon.com</a></div><div style="font-family: Arial;"><b>Quantum Mechanics : </b><a href="http://www.cdbaby.com/cd/gabrielebulfon" target="_new">http://www.cdbaby.com/cd/gabrielebulfon</a></div></div><tt><br><br><br>----------------------------------------------------------------------------------<br><br>Da: Dejan Muhamedagic <dejanmm@fastmail.fm><br>A: kgaillot@redhat.com Cluster Labs - All topics related to open-source clustering welcomed <users@clusterlabs.org> <br>Data: 29 agosto 2016 16.43.52 CEST<br>Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables<br><br></tt><blockquote style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"><tt>Hi,<br><br>On Mon, Aug 29, 2016 at 08:47:43AM -0500, Ken Gaillot wrote:<br>> On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:<br>> > Hi Ken,<br>> > <br>> > I have been talking with the illumos guys about the shell problem.<br>> > They all agreed that ksh (and specially the ksh93 used in illumos) is<br>> > absolutely Bourne-compatible, and that the "local" variables used in the<br>> > ocf shells is not a Bourne syntax, but probably a bash specific.<br>> > This means that pointing the scripts to "#!/bin/sh" is portable as long<br>> > as the scripts are really Bourne-shell only syntax, as any Unix variant<br>> > may link whatever Bourne-shell they like.<br>> > In this case, it should point to "#!/bin/bash" or whatever shell the<br>> > script was written for.<br>> > Also, in this case, the starting point is not the ocf-* script, but the<br>> > original RA (IPaddr, but almost all of them).<br>> > <br>> > What about making the code base of RA and ocf-* portable?<br>> > It may be just by changing them to point to bash, or with some kind of<br>> > configure modifier to be able to specify the shell to use.<br>> > <br>> > Meanwhile, changing the scripts by hands into #!/bin/bash worked like a<br>> > charm, and I will start patching.<br>> > <br>> > Gabriele<br>> <br>> Interesting, I thought local was posix, but it's not. It seems everyone<br>> but solaris implemented it:<br>> <br>> http://stackoverflow.com/questions/18597697/posix-compliant-way-to-scope-variables-to-a-function-in-a-shell-script<br>> <br>> Please open an issue at:<br>> <br>> https://github.com/ClusterLabs/resource-agents/issues<br>> <br>> The simplest solution would be to require #!/bin/bash for all RAs that<br>> use local,<br><br>This issue was raised many times, but note that /bin/bash is a<br>shell not famous for being lean: it's great for interactive use,<br>but not so great if you need to run a number of scripts. The<br>complexity in bash, which is superfluous for our use case,<br>doesn't go well with the basic principles of HA clusters.<br><br>> but I'm not sure that's fair to the distros that support<br>> local in a non-bash default shell. Another possibility would be to<br>> modify all RAs to avoid local entirely, by using unique variable<br>> prefixes per function.<br><br>I doubt that we could do a moderately complex shell scripts<br>without capability of limiting the variables' scope and retaining<br>sanity at the same time.<br><br>> Or, it may be possible to guard every instance of<br>> local with a check for ksh, which would use typeset instead. Raising the<br>> issue will allow some discussion of the possibilities.<br><br>Just to mention that this is the first time someone reported<br>running a shell which doesn't support local. Perhaps there's an<br>option that they install a shell which does.<br><br>Thanks,<br><br>Dejan<br><br>> > <br>> > ----------------------------------------------------------------------------------------<br>> > *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/><br>> > *Music: *http://www.gabrielebulfon.com <http://www.gabrielebulfon.com/><br>> > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br>> > <br>> > <br>> > <br>> > ----------------------------------------------------------------------------------<br>> > <br>> > Da: Ken Gaillot <kgaillot@redhat.com><br>> > A: gbulfon@sonicle.com Cluster Labs - All topics related to open-source<br>> > clustering welcomed <users@clusterlabs.org><br>> > Data: 26 agosto 2016 15.56.02 CEST<br>> > Oggetto: Re: ocf scripts shell and local variables<br>> > <br>> >     On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:<br>> >     > I tried adding some debug in ocf-shellfuncs, showing env and ps<br>> >     -ef into<br>> >     > the corosync.log<br>> >     > I suspect it's always using ksh, because in the env output I<br>> >     produced I<br>> >     > find this: KSH_VERSION=.sh.version<br>> >     > This is normally not present in the environment, unless ksh is running<br>> >     > the shell.<br>> > <br>> >     The RAs typically start with #!/bin/sh, so whatever that points to on<br>> >     your system is what will be used.<br>> > <br>> >     > I also tried modifiying all ocf shells with "#!/usr/bin/bash" at the<br>> >     > beginning, no way, same output.<br>> > <br>> >     You'd have to change the RA that includes them.<br>> > <br>> >     > Any idea how can I change the used shell to support "local" variables?<br>> > <br>> >     You can either edit the #!/bin/sh line at the top of each RA, or figure<br>> >     out how to point /bin/sh to a Bourne-compatible shell. ksh isn't<br>> >     Bourne-compatible, so I'd expect lots of #!/bin/sh scripts to fail with<br>> >     it as the default shell.<br>> > <br>> >     > Gabriele<br>> >     ><br>> >     ><br>> >     ----------------------------------------------------------------------------------------<br>> >     > *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/><br>> >     > *Music: *http://www.gabrielebulfon.com<br>> >     <http://www.gabrielebulfon.com/><br>> >     > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br>> >     ><br>> >     ><br>> >     ------------------------------------------------------------------------<br>> >     ><br>> >     ><br>> >     > *Da:* Gabriele Bulfon <gbulfon@sonicle.com><br>> >     > *A:* kgaillot@redhat.com Cluster Labs - All topics related to<br>> >     > open-source clustering welcomed <users@clusterlabs.org><br>> >     > *Data:* 26 agosto 2016 10.12.13 CEST<br>> >     > *Oggetto:* Re: [ClusterLabs] ocf::heartbeat:IPaddr<br>> >     ><br>> >     ><br>> >     > I looked around what you suggested, inside ocf-binaris and<br>> >     > ocf-shellfuncs etc.<br>> >     > So I found also these logs in corosync.log :<br>> >     ><br>> >     > Aug 25 17:50:33 [2250] crmd: notice: process_lrm_event:<br>> >     > xstorage1-xstorage2_wan2_IP_start_0:22 [<br>> >     > /usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No<br>> >     > such file or<br>> >     > directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[354]: local:<br>> >     > not found [No such file or<br>> >     > directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[355]: local:<br>> >     > not found [No such file or<br>> >     > directory]\n/usr/lib/ocf/resource.d/heartbeat/IPaddr[356]: local:<br>> >     > not found [No such file or directory]\nocf-exit-reason:Setup<br>> >     > problem: coul<br>> >     ><br>> >     > Aug 25 17:50:33 [2246] lrmd: notice: operation_finished:<br>> >     > xstorage2_wan2_IP_start_0:3613:stderr [<br>> >     > /usr/lib/ocf/resource.d/heartbeat/IPaddr[71]: local: not found [No<br>> >     > such file or directory] ]<br>> >     ><br>> >     > Looks like the shell is not happy with the "local" variable<br>> >     definition.<br>> >     > I tried running ocf-shellfuncs manually with sh and bash and they<br>> >     > all run without errors.<br>> >     > How can I see what shell is running these scripts?<br>> >     ><br>> >     ><br>> >     ----------------------------------------------------------------------------------------<br>> >     > *Sonicle S.r.l. *: http://www.sonicle.com <http://www.sonicle.com/><br>> >     > *Music: *http://www.gabrielebulfon.com<br>> >     <http://www.gabrielebulfon.com/><br>> >     > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br>> >     ><br>> >     ><br>> >     ><br>> >     ><br>> >     ----------------------------------------------------------------------------------<br>> >     ><br>> >     > Da: Ken Gaillot <kgaillot@redhat.com><br>> >     > A: users@clusterlabs.org<br>> >     > Data: 25 agosto 2016 18.07.42 CEST<br>> >     > Oggetto: Re: [ClusterLabs] ocf::heartbeat:IPaddr<br>> >     ><br>> >     > On 08/25/2016 10:51 AM, Gabriele Bulfon wrote:<br>> >     > > Hi,<br>> >     > ><br>> >     > > I'm advancing with this monster cluster on XStreamOS/illumos ;)<br>> >     > ><br>> >     > > In the previous older tests I used heartbeat, and I had these<br>> >     > lines to<br>> >     > > take care of the swapping public IP addresses:<br>> >     > ><br>> >     > > primitive xstorage1_wan1_IP ocf:heartbeat:IPaddr params<br>> >     > ip="1.2.3.4"<br>> >     > > cidr_netmask="255.255.255.0" nic="e1000g1"<br>> >     > > primitive xstorage2_wan2_IP ocf:heartbeat:IPaddr params<br>> >     > ip="1.2.3.5"<br>> >     > > cidr_netmask="255.255.255.0" nic="e1000g1"<br>> >     > ><br>> >     > > location xstorage1_wan1_IP_pref xstorage1_wan1_IP 100: xstorage1<br>> >     > > location xstorage2_wan2_IP_pref xstorage2_wan2_IP 100: xstorage2<br>> >     > ><br>> >     > > They get configured, but then I get this in crm status:<br>> >     > ><br>> >     > > xstorage1_wan1_IP (ocf::heartbeat:IPaddr): Stopped<br>> >     > > xstorage2_wan2_IP (ocf::heartbeat:IPaddr): Stopped<br>> >     > ><br>> >     > > Failed Actions:<br>> >     > > * xstorage1_wan1_IP_start_0 on xstorage1 'not installed' (5):<br>> >     > call=20,<br>> >     > > status=complete, exitreason='Setup problem: couldn't find command:<br>> >     > > /usr/bin/gawk',<br>> >     > > last-rc-change='Thu Aug 25 17:50:32 2016', queued=1ms, exec=158ms<br>> >     > > * xstorage2_wan2_IP_start_0 on xstorage1 'not installed' (5):<br>> >     > call=22,<br>> >     > > status=complete, exitreason='Setup problem: couldn't find command:<br>> >     > > /usr/bin/gawk',<br>> >     > > last-rc-change='Thu Aug 25 17:50:33 2016', queued=1ms, exec=29ms<br>> >     > > * xstorage1_wan1_IP_start_0 on xstorage2 'not installed' (5):<br>> >     > call=22,<br>> >     > > status=complete, exitreason='Setup problem: couldn't find command:<br>> >     > > /usr/bin/gawk',<br>> >     > > last-rc-change='Thu Aug 25 17:50:30 2016', queued=1ms, exec=36ms<br>> >     > > * xstorage2_wan2_IP_start_0 on xstorage2 'not installed' (5):<br>> >     > call=20,<br>> >     > > status=complete, exitreason='Setup problem: couldn't find command:<br>> >     > > /usr/bin/gawk',<br>> >     > > last-rc-change='Thu Aug 25 17:50:29 2016', queued=0ms, exec=150ms<br>> >     > ><br>> >     > ><br>> >     > > The crm configure process already checked of the presence of the<br>> >     > > required IPaddr shell, and it was ok.<br>> >     > > Now looks like it's looking for "/usr/bin/gawk", and that is<br>> >     > actually there!<br>> >     > > Is there any known incompatibility with the mixed heartbeat<br>> >     > ocf ? Should<br>> >     > > I use corosync specific ocf files or something else?<br>> >     ><br>> >     > "heartbeat" in this case is just an OCF provider name, and has<br>> >     > nothing<br>> >     > to do with the heartbeat messaging layer, other than having its<br>> >     > origin<br>> >     > in the same project. There actually has been a recent proposal<br>> >     > to rename<br>> >     > the provider to "clusterlabs" to better reflect the current reality.<br>> >     ><br>> >     > The "couldn't find command" message comes from the ocf-binaries<br>> >     > shell<br>> >     > functions. If you look at have_binary() there, it uses sed and<br>> >     > which,<br>> >     > and I'm guessing that fails on your OS somehow. You may need to<br>> >     > patch it.<br>> >     ><br>> >     > > Thanks again!<br>> >     > ><br>> >     > > Gabriele<br>> >     > ><br>> >     > ><br>> >     ><br>> >     ----------------------------------------------------------------------------------------<br>> >     > > *Sonicle S.r.l. *: http://www.sonicle.com<br>> >     > <http://www.sonicle.com/><br>> >     > > *Music: *http://www.gabrielebulfon.com<br>> >     > <http://www.gabrielebulfon.com/><br>> >     > > *Quantum Mechanics : *http://www.cdbaby.com/cd/gabrielebulfon<br>> <br>> _______________________________________________<br>> Users mailing list: Users@clusterlabs.org<br>> http://clusterlabs.org/mailman/listinfo/users<br>> <br>> Project Home: http://www.clusterlabs.org<br>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>> Bugs: http://bugs.clusterlabs.org<br><br>_______________________________________________<br>Users mailing list: Users@clusterlabs.org<br>http://clusterlabs.org/mailman/listinfo/users<br><br>Project Home: http://www.clusterlabs.org<br>Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>Bugs: http://bugs.clusterlabs.org<br><br><br></tt></blockquote></div>