[Puppet - Bug #18266] (Duplicate) init provider fails to manage (ensure = stopped) a service which init script does not exist anymore
Issue #18266 has been updated by Peter Meier.
Status changed from Unreviewed to Duplicate
is a dup of #17286
Bug #18266: init provider fails to manage (ensure = stopped) a service which
init script does not exist anymore
https://projects.puppetlabs.com/issues/18266#change-79393
Author: Peter Meier
Status: Duplicate
Priority: Normal
Assignee:
Category: service
Target version:
Affected Puppet version: 3.0.1
Keywords: debian, service, init, provider
Branch:
On a debian stable system:
pre
# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 6.0.6 (squeeze)
Release:6.0.6
Codename: squeeze
/pre
Trying to ensure that a service is stopped (and later package to be removed)
fails on subsequent runs, when the service is already stopped and gone. The
problem is that the init provider tries to find an init-script which isn't
there anymore = fails to determine status.
pre
# cat test.pp
service{'sendmail':
ensure= stopped,
enable= false,
hasstatus = true,
}
# puppet apply --debug test.pp
debug: Puppet::Type::Service::ProviderRedhat: file /sbin/service does not exist
debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does not
exist
debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not exist
debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does not
exist
debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svstat does
not exist
debug: Creating default schedules
debug: Failed to load library 'selinux' for feature 'selinux'
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Puppet::Type::User::ProviderLdap: true value when expecting false
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does
not exist
debug: Puppet::Type::User::ProviderUser_role_add: file rolemod does not exist
debug: Puppet::Type::File::ProviderMicrosoft_windows: feature microsoft_windows
is missing
debug: Failed to load library 'ldap' for feature 'ldap'
debug: /File[/var/lib/puppet/ssl/private]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/public_keys/tramp.glei.ch.pem]: Autorequiring
File[/var/lib/puppet/ssl/public_keys]
debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/private_keys/tramp.glei.ch.pem]: Autorequiring
File[/var/lib/puppet/ssl/private_keys]
debug: /File[/var/lib/puppet/state/last_run_summary.yaml]: Autorequiring
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state/graphs]: Autorequiring
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state/classes.txt]: Autorequiring
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs/tramp.glei.ch.pem]: Autorequiring
File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/state/last_run_report.yaml]: Autorequiring
File[/var/lib/puppet/state]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring
File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/lib/puppet]
debug: Finishing transaction -614010188
debug: Loaded state in 0.77 seconds
debug: Loaded state in 0.77 seconds
info: Applying configuration version '1356345789'
debug: Service[sendmail](provider=debian): Could not find sendmail in
/etc/init.d
debug: Service[sendmail](provider=debian): Could not find sendmail.sh in
/etc/init.d
/usr/lib/ruby/1.8/puppet/provider/service/init.rb:116:in `search'
/usr/lib/ruby/1.8/puppet/provider/service/init.rb:70:in `initscript'
/usr/lib/ruby/1.8/puppet/provider/service/init.rb:137:in `statuscmd'
/usr/lib/ruby/1.8/puppet/provider/service/base.rb:58:in `status'
/usr/lib/ruby/1.8/puppet/type/service.rb:73:in `retrieve'
/usr/lib/ruby/1.8/puppet/type.rb:685:in `retrieve'
/usr/lib/ruby/1.8/puppet/type.rb:703:in `retrieve_resource'
/usr/lib/ruby/1.8/puppet/transaction/resource_harness.rb:32:in `perform_changes'
/usr/lib/ruby/1.8/puppet/transaction/resource_harness.rb:133:in `evaluate'
[Puppet - Bug #17286] Debian client looking for init script even when it shouldn't be there.
Issue #17286 has been updated by Peter Meier. I've posted more information in my duplicated report #18266 In short: problem is only if hasstatus is set to true. RH works fine, because the redhat provider invokes service $name which fails anyway if the init.d script is not present - service assumed to be stopped. Still, I think it should not fail if we want to have the service stopped. Bug #17286: Debian client looking for init script even when it shouldn't be there. https://projects.puppetlabs.com/issues/17286#change-79394 Author: Greg Swift Status: Re-opened Priority: Normal Assignee: eric sorenson Category: Target version: Affected Puppet version: 3.0.1 Keywords: Branch: I was working on our internal time module. I'm attaching a very generic version of it. Basically when the class is set 'ensure = absent' it ensures that the package is gone and the service is stopped and disabled. My service requires the package, so in theory it shouldn't run the service resource if the package is absent. But every run on a debian system it throws the following error: Error: /Stage[main]/Basictime/Service[ntp]: Could not evaluate: Could not find init script for 'ntp' Also attaching full output. Testing with 2.7.18 from debian's squeeze testing, 2.7.19 and 3.0.1 from apt.puppetlabs. This part works fine on CentOS (I have a different issue on that side) -- 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 puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17288] a file resource will GET the source, even when ensure is set to absent.
Issue #17288 has been updated by Peter Meier.
that's why I usually set the source only if I want the file to be present. But
yeah it would be better if it wouldn't be fetched if it should be absent in the
end.
Bug #17288: a file resource will GET the source, even when ensure is set to
absent.
https://projects.puppetlabs.com/issues/17288#change-79395
Author: Ben Ford
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
This is kind of a nonsense situation, except for code such as this:
define userconfig::p4include (
$ensure = present,
$source = 'puppet:///modules/userconfig/p4include'
) {
# This will cut down on extra network requests
$real_source = $ensure ? {
absent = undef,
default = $source,
}
file { /home/${name}/.p4include:
ensure = $ensure,
source = $real_source,
}
}
Without the selector, the source is always queried, causing extra overhead, and
failing if the source doesn't exist. Even if you're ensuring absent.
--
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 puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17278] Double entry when using nagios_host
Issue #17278 has been updated by Peter Meier. looks like a dup of #17871 Bug #17278: Double entry when using nagios_host https://projects.puppetlabs.com/issues/17278#change-79396 Author: Alexandre Angel Status: Unreviewed Priority: Urgent Assignee: Category: nagios Target version: 3.0.x Affected Puppet version: 3.0.1 Keywords: Branch: Hello, Since upgrade to puppet 3, i have a problem with nagios_host used in local. I have a class creating nagios_host type. At first run, it works fine, nagios config file is ok. On the second run, one of them is added a second time to the nagios confif file like puppet failed to see it's already present in the file. If i try to not add that nagios_host, another one i add is added a second time. The bugging nagios_host is always the first in file generated. I guess it miss the first element when checking for existing host. Here is log from puppet agent --debug --verbose --no-daemonize concerning nagios_host : 1st run : Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event 2nd run : Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event /Stage[main]/Nagios::Target/Nagios_host[webadmin.mydomain.com]/parents: parents changed ['sbx908.mydomain.com'] to 'sbx908.mydomain.com' Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event -- 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 puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18109] Class namespace declaration appears to be dynamically scoped
Issue #18109 has been updated by Peter Meier.
it's certainly the behavior that has been here for a very long time. So imho it
should be documented how it works currently and if it is revised, it should
certainly be changed only with a warning message and deprecation cycle.
Bug #18109: Class namespace declaration appears to be dynamically scoped
https://projects.puppetlabs.com/issues/18109#change-79397
Author: Chris Spence
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version: 2.7.19
Keywords:
Branch:
In the example below, the class declaration test generates an error
class role::test {
class { 'test': }
#include test
}
Duplicate declaration: Class[Role::Test] is already declared; cannot
redeclare at /etc/puppetlabs/puppet/modules/role/manifests/test.pp:2
as it appears to be attempting to redeclare itself due to dynamic namespacing
in the class { 'test': } declaration.
the 'include test' line also doesn't do the 'right thing' because it declares
the role::test class, however include ::test does the right thing
The workaround is to declare class { '::test': } (or include ::test) , however
I wouldn't expect class declaration lookup to be dynamic as a default - I can
see that dynamic lookup would cause this to happen, but wonder if this
behaviour should be reviewed.
--
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 puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18053] source attribute not honored for gem provider
Issue #18053 has been updated by Stefan Schulte. Gem seems to try to fetch `http://rubygems.org/latest_specs.4.8.gz`. Is this supposed to happen/work? I'm trying to understand why the gem command may behave differently when running through puppet. Are there any environment settings (proxy settings etc) that might cause gem to behave differently? If you unset the following environment variables, does it still work from the commandline? pre unset LANG LC_ALL LC_MESSAGES LANGUAGE LC_COLLATE LC_CTYPE LC_MONETARY LC_NUMERIC LC_TIME unset HOME USER LOGNAME /pre Bug #18053: source attribute not honored for gem provider https://projects.puppetlabs.com/issues/18053#change-79398 Author: Gerard Hickey Status: Needs More Information Priority: Normal Assignee: Gerard Hickey Category: package Target version: Affected Puppet version: 3.0.1 Keywords: Branch: When attempting to provide another source for a package resource using the gem provider, the install fails. Error output from 'puppet agent -tv': pre Error: Execution of '/usr/bin/gem install --include-dependencies --source http://internal.gemrepo.com/ passenger' returned 1: ERROR: Could not find a valid gem 'passenger' (= 0) in any repository ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) Errno::ETIMEDOUT: Connection timed out - connect(2) (http://rubygems.org/latest_specs.4.8.gz) INFO: `gem install -y` is now default and will be removed INFO: use --ignore-dependencies to install only the gems you list Error: /Stage[main]/Puppet::Master/Package[passenger]/ensure: change from absent to present failed: Execution of '/usr/bin/gem install --include-dependencies --source http://internal.gemrepo.com/ passenger' returned 1: ERROR: Could not find a valid gem 'passenger' (= 0) in any repository ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) Errno::ETIMEDOUT: Connection timed out - connect(2) (http://rubygems.org/latest_specs.4.8.gz) INFO: `gem install -y` is now default and will be removed INFO: use --ignore-dependencies to install only the gems you list Finished catalog run in 106.88 seconds ghickey@slc4b01c-69c8:rack:6$ gem source *** CURRENT SOURCES *** http://rubygems.org/ ghickey@slc4b01c-69c8:rack:0$ sudo gem install --include-dependencies --source http://internal.gemrepo.com/ passenger [sudo] password for ghickey: INFO: `gem install -y` is now default and will be removed INFO: use --ignore-dependencies to install only the gems you list Fetching: fastthread-1.0.7.gem (100%) Building native extensions. This could take a while... Fetching: daemon_controller-1.1.0.gem (100%) Fetching: passenger-3.0.18.gem (100%) Successfully installed fastthread-1.0.7 Successfully installed daemon_controller-1.1.0 Successfully installed passenger-3.0.18 3 gems installed Installing ri documentation for fastthread-1.0.7... Installing ri documentation for daemon_controller-1.1.0... Installing ri documentation for passenger-3.0.18... Installing RDoc documentation for fastthread-1.0.7... Installing RDoc documentation for daemon_controller-1.1.0... Installing RDoc documentation for passenger-3.0.18... /pre The system that produced the output is behind a firewall and can not directly connect to rubygems.org. There is an internal gem repo inside the firewall that contains mirrored gems for the purpose of distributing within the firewall. As you can see if the same command is executed from the command line, it succeeds. -- 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 puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18234] Booleans used from within hashes not working correctly.
Issue #18234 has been updated by Peter Meier.
Andrew Hendry wrote:
Thanks for the pointer.
Changing the line you mentioned to this appears to be working so far our on
2.7.14 puppet master.
[...]
I would try to omit is_a?
pre
value = object[array_index_or_key(object, accesskey)]
if value.nil?
:undef
else
value
end
/pre
Or a less verbose solution would be
pre
(value=object[array_index_or_key(object, accesskey)]).nil? ? :undef : value
/pre
Bug #18234: Booleans used from within hashes not working correctly.
https://projects.puppetlabs.com/issues/18234#change-79399
Author: Andrew Hendry
Status: Accepted
Priority: Normal
Assignee:
Category: language
Target version:
Affected Puppet version:
Keywords: puppet hashes booleans defaults evaluation
Branch:
booleans_from_hashes.pp
pre$puppet_hash = {
hflag1 = true,
hflag2 = false
}
notice(hflag1 should be true = '${puppet_hash[hflag1]}')
notice(hflag2 should be false = '${puppet_hash[hflag2]}')
dummy {'fromhash':
flag1 = $puppet_hash[hflag1],
flag2 = $puppet_hash[hflag2]
}
dummy {'assigned':
flag1 = true,
flag2 = false
}
define dummy
(
$flag1 = true,
$flag2 = true,
) {
notice(${name} flag1 should be true = '${flag1}')
notice(${name} flag2 should be false = '${flag2}')
}
/pre
Output:
pre
puppet apply booleans_from_hashes.pp
notice: Scope(Class[main]): hflag1 should be true = 'true'
notice: Scope(Class[main]): hflag2 should be false = ''
notice: Scope(Dummy[fromhash]): fromhash flag1 should be true = 'true'
notice: Scope(Dummy[fromhash]): fromhash flag2 should be false = 'true'
notice: Scope(Dummy[assigned]): assigned flag1 should be true = 'true'
notice: Scope(Dummy[assigned]): assigned flag2 should be false = 'false'
notice: Finished catalog run in 0.04 seconds
/pre
pre
puppet --version
2.7.14
ruby --version
ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
/pre
flag2 should be false when pulled from the hash but it appears to be empty,
resulting in the default being used.
This does not happen when passing booleans directly.
Does anyone know a workaround or fix?
--
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 puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
