Issue #13325 has been updated by Daniel Pittman.

Jeremy Rosengren wrote:
> Argh... of course this is what's happening.  I just needed somebody to 
> express the problem in those terms.

...and just following up on this for the future audience:

The `daemon` method there *correctly* strips out most stuff in the environment, 
so that random stuff from the user invoking the service doesn't end up 
accidentally changing the behaviour of the thing.  So, this is normal: if you 
want your daemon to have something in the environment, you need to make the 
init script configure that, not just rely on your environment being inherited.
----------------------------------------
Bug #13325: CentOS /etc/init.d/puppet, puppetd run under "daemon" doesn't 
properly run custom facts.
https://projects.puppetlabs.com/issues/13325#change-58538

Author: Jeremy Rosengren
Status: Closed
Priority: Normal
Assignee: Jeremy Rosengren
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


    Ruby version:  ruby-1.8.5-19.el5_6.1
    Puppet version:  puppet-2.7.12-1.el5
    Facter version:  facter-1.6.6-1.el5
    CentOS version:  5.7

I have a custom fact called /var/lib/puppet/lib/facter/oraclehome.rb that 
determines the Oracle home location for the Oracle installation.  I use this 
information to modify /etc/init.d/oracle (script that starts/stops the DB).  
The custom fact looks like this:

    Facter.add(:oraclehome) do
      setcode do
        if ENV['ORACLE_HOME']
          ENV['ORACLE_HOME']
        end
      end
    end

If I run either:  puppet agent --test, puppetd --test, puppet agent, or puppetd 
manually from the command-line, the oraclehome.rb generates the correct 
information and /etc/init.d/oracle is modified correctly.  If I run "service 
puppet start", the init script provided by the puppet-2.7.12-1.el5 package 
obtained from Puppetlabs' repository, the oraclehome.rb custom fact is unable 
to determine the Oracle home location with the result being that the 
/etc/init.d/oracle file Oracle home setting is emptied.

It seems like this is the section in the /etc/init.d/puppet script that's 
causing the problems:

    start() {
        echo -n $"Starting puppet: "
        daemon $daemonopts $puppetd ${PUPPET_OPTS} ${PUPPET_EXTRA_OPTS}

I couldn't find any mentions of this particular behavior on the mailing list or 
in other tickets.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

Reply via email to