Issue #3184 has been updated by Peter Meier. Status changed from Unreviewed to Rejected
> Puppet thinks that cron on Gentoo is always stopped. I think this may stem > from the issue that the Gentoo package name for cron is actually vixie-cron, > but the binary running is named cron. It looks like a work around may be to > define two separate services, one for vixie-cron and one for cron? Looking > at the debug output, this makes sense, but from a user's standpoint, > shouldn't puppet be aware of how cron works for gentoo? no the issue is rather that the init.d script is called vixie-cron and the process running cron. However this how puppet is supposed to work, as puppet determines the process-name from the script-name. You have to options: * If the vixie-cron script supports @status@ you can set @hasstatus => true@ and puppet will execute @/etc/init.d/vixie-cron status@ to determine the current state. This parameter is false by default on most distributions as many distributions don't enforce @status@ commands for their init.d scripts. * You can change the @pattern@ parameter of the vixi-cron service to determine the correct process running. Have a look at the type documentation for further information about that. As this is within the supposed behavior of puppet I reject the ticket. If somebody disagrees or has further information please re-open with additional information. ---------------------------------------- Bug #3184: Puppet thinks Gentoo cron always in "stopped" state http://projects.reductivelabs.com/issues/3184 Author: Daniel Beckham Status: Rejected Priority: Normal Assigned to: Category: Target version: Affected version: 0.25.4 Keywords: Branch: Puppet thinks that cron on Gentoo is always stopped. I think this may stem from the issue that the Gentoo package name for cron is actually vixie-cron, but the binary running is named cron. It looks like a work around may be to define two separate services, one for vixie-cron and one for cron? Looking at the debug output, this makes sense, but from a user's standpoint, shouldn't puppet be aware of how cron works for gentoo? Simple output from --test --noop: <pre> puppethost ~ # puppetd --test --noop info: Caching catalog for puppethost.mydomain.com info: Applying configuration version '1266015652' notice: //cron/Service[vixie-cron]/ensure: is stopped, should be running (noop) notice: Finished catalog run in 0.37 seconds </pre> The same error shows up in syslog every 30 minutes when puppet syncs with the master. The puppet config being used: <pre> class cron { service { "vixie-cron": enable => "true", ensure => "running" } } </pre> Actual debug log output: <pre> puppethost ~ # puppetd --test --noop --trace --verbose --debug debug: Failed to load library 'selinux' for feature 'selinux' debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist 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: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/lib/puppet/state] debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/ssl/private]: Autorequiring File[/var/lib/puppet/ssl] debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/ssl/certs/puppethost.mydomain.com.pem]: Autorequiring File[/var/lib/puppet/ssl/certs] debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/puppet/ssl] debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring File[/var/lib/puppet/ssl/certs] debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet] debug: /File[/var/run/puppet/puppetd.pid]: Autorequiring File[/var/run/puppet] debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring File[/var/lib/puppet/ssl] debug: /File[/var/lib/puppet/classes.txt]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring File[/var/lib/puppet/ssl] debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/var/lib/puppet/state] debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring File[/var/lib/puppet/ssl] debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet] debug: /File[/var/lib/puppet/ssl/public_keys/puppethost.mydomain.com.pem]: Autorequiring File[/var/lib/puppet/ssl/public_keys] debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet] debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring File[/var/lib/puppet/ssl] debug: /File[/var/lib/puppet/ssl/private_keys/puppethost.mydomain.com.pem]: Autorequiring File[/var/lib/puppet/ssl/private_keys] debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet] debug: Finishing transaction 23700111455480 with 0 changes debug: Using cached certificate for ca, good until Fri Jul 04 14:25:50 UTC 2014 debug: Using cached certificate for puppethost.mydomain.com, good until Sat Dec 27 21:37:25 UTC 2014 debug: Loaded state in 0.00 seconds debug: Using cached certificate for ca, good until Fri Jul 04 14:25:50 UTC 2014 debug: Using cached certificate for puppethost.mydomain.com, good until Sat Dec 27 21:37:25 UTC 2014 debug: Using cached certificate_revocation_list for ca, good until debug: catalog supports formats: b64_zlib_yaml marshal pson raw yaml; using pson info: Caching catalog for mydomain.com.mydomain.com debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d does not exist debug: Puppet::Type::Service::ProviderRedhat: file /sbin/chkconfig does not exist debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc 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: Creating default schedules debug: Finishing transaction 23700111541020 with 0 changes debug: Loaded state in 0.00 seconds debug: //snmp::server/File[/etc/snmp/snmpd.conf]: Autorequiring File[/etc/snmp] info: Applying configuration version '1266015652' debug: Service[snmpd](provider=gentoo): Executing 'ps -ef' debug: Service[snmpd](provider=gentoo): PID is 22402 debug: Puppet::Type::Service::ProviderGentoo: Executing '/sbin/rc-update show' debug: Service[syslog-ng](provider=gentoo): Executing 'ps -ef' debug: Service[syslog-ng](provider=gentoo): PID is 20318 debug: Puppet::Type::Service::ProviderGentoo: Executing '/sbin/rc-update show' debug: Puppet::Type::Service::ProviderGentoo: Executing '/sbin/rc-update show' debug: Service[ntpd](provider=gentoo): Executing 'ps -ef' debug: Service[ntpd](provider=gentoo): PID is 15832 debug: Puppet::Type::Service::ProviderGentoo: Executing '/sbin/rc-update show' debug: Service[sshd](provider=gentoo): Executing 'ps -ef' debug: Service[sshd](provider=gentoo): PID is 22459 debug: Puppet::Type::Service::ProviderGentoo: Executing '/sbin/rc-update show' debug: Service[vixie-cron](provider=gentoo): Executing 'ps -ef' debug: Puppet::Type::Service::ProviderGentoo: Executing '/sbin/rc-update show' debug: //cron/Service[vixie-cron]: Changing ensure debug: //cron/Service[vixie-cron]: 1 change(s) notice: //cron/Service[vixie-cron]/ensure: is stopped, should be running (noop) debug: Finishing transaction 23700111516860 with 1 changes debug: Storing state debug: Stored state in 0.02 seconds notice: Finished catalog run in 0.36 seconds </pre> -- 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://reductivelabs.com/redmine/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.
