Argh. I have the definition below. The gluster peer probe command has
already been executed successfully, and I''m testing it with
''peer
status''. Running the unless=> command yields:
root@gfs01:~# /usr/sbin/gluster peer status | /bin/grep gfs02.us1.xxx.com
Hostname: gfs02.us1.xxx.com
root@gfs01:~# echo $?
0
Therefore, the command should never run again, but it is, as evidenced
by the fact that /tmp/foo keeps getting X appended to it.
define glusterfs::probe_peer ( $ensure, $master_node ) {
if $master_node == $::fqdn {
case $ensure {
''probed'': {
exec {
"add-peer-$name":
#command => "/usr/sbin/gluster peer probe
$name",
command => "/bin/echo X >> /tmp/foo",
logoutput => true,
unless => "/usr/sbin/gluster peer status |
/bin/grep $name";
}
}
}
}
}
Doug.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Monday, August 27, 2012 5:39:36 PM UTC-5, Douglas wrote:> > Argh. I have the definition below. The gluster peer probe command has > already been executed successfully, and I''m testing it with ''peer > status''. Running the unless=> command yields: > > root@gfs01:~# /usr/sbin/gluster peer status | /bin/grep gfs02.us1.xxx.com > Hostname: gfs02.us1.xxx.com > root@gfs01:~# echo $? > 0 > > Therefore, the command should never run again, but it is, as evidenced > by the fact that /tmp/foo keeps getting X appended to it. > > define glusterfs::probe_peer ( $ensure, $master_node ) { > > if $master_node == $::fqdn { > case $ensure { > ''probed'': { > exec { > "add-peer-$name": > #command => "/usr/sbin/gluster peer probe $name", > command => "/bin/echo X >> /tmp/foo", > logoutput => true, > unless => "/usr/sbin/gluster peer status | > /bin/grep $name"; > } > } > } > } > } > >Usually this kind of problem arises when the command being run (the ''unless'' command in this case) relies on an environment variable whose presence or value differs in an interactive shell from what the (very sparse) environment in which an Exec runs things. In this case, I also don''t have enough information to rule out the possibility that $name''s value differs from the expected value of "gfs02.us1.xxx.com <http://gfs02.us1.xxx.com>". John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/aOuMVbKCDKIJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks. This one turned out to be user error. :) On Tue, Aug 28, 2012 at 7:08 AM, jcbollinger <John.Bollinger@stjude.org> wrote:> > > On Monday, August 27, 2012 5:39:36 PM UTC-5, Douglas wrote: >> >> Argh. I have the definition below. The gluster peer probe command has >> already been executed successfully, and I''m testing it with ''peer >> status''. Running the unless=> command yields: >> >> root@gfs01:~# /usr/sbin/gluster peer status | /bin/grep gfs02.us1.xxx.com >> Hostname: gfs02.us1.xxx.com >> root@gfs01:~# echo $? >> 0 >> >> Therefore, the command should never run again, but it is, as evidenced >> by the fact that /tmp/foo keeps getting X appended to it. >> >> define glusterfs::probe_peer ( $ensure, $master_node ) { >> >> if $master_node == $::fqdn { >> case $ensure { >> ''probed'': { >> exec { >> "add-peer-$name": >> #command => "/usr/sbin/gluster peer probe $name", >> command => "/bin/echo X >> /tmp/foo", >> logoutput => true, >> unless => "/usr/sbin/gluster peer status | >> /bin/grep $name"; >> } >> } >> } >> } >> } >> > > Usually this kind of problem arises when the command being run (the ''unless'' > command in this case) relies on an environment variable whose presence or > value differs in an interactive shell from what the (very sparse) > environment in which an Exec runs things. > > In this case, I also don''t have enough information to rule out the > possibility that $name''s value differs from the expected value of > "gfs02.us1.xxx.com". > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/aOuMVbKCDKIJ. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en.-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@gmail.com Cell: +1-805-340-5627 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.