Issue #15911 has been updated by Vincent Gallissot.
File puppet_agent_2.7.18.log added
File puppet_agent_3.1.0.log added
Hi everyone,
I installed puppet via official repos (2.7.18) and from your repo
(yum.puppetlabs.com 3.1.0) on Fedora 18.
The Feature #15911 propose to automatic .service suffix systemd services. It's
less a feature than an obligation :
As you can see in my two logs (running 'puppet agent -t -d' on my node) puppet
tries to do the following :
Debug: Executing '/bin/systemctl is-active sssd'
Debug: Executing '/bin/systemctl is-enabled sssd'
Debug: Executing '/bin/systemctl enable sssd'
Notice: /Stage[main]/Sys_ldap::Sssd/Service[sssd]/enable: enable changed
'false' to 'true'
In facts, 'is-enabled' requires .service extention and if you don't, here is
the error :
[root@cypres install]# /bin/systemctl is-enabled sssd
Failed to issue method call: Invalid argument
[root@cypres install]# /bin/systemctl is-enabled sssd.service
enabled
So each time puppet is run it defines the service on 'disabled' cause the
'is-enabled' command doesn't return 0.
I run puppet agent many times and it always says "enable changed 'false' to
'true'" on all my services.
Another point is that puppet from official repos and from your repo still uses
sysVinit on fedora >15 for the system part.
The trick that allows not to add ".service" after services for systemd commands
only run for nativ systemd services. For the sysVinit retrocompatibility part,
it doesn't work at all and you must use puppet.service on every commands to
make it run.
See in logs :
Debug: Executing '/bin/systemctl is-active puppet'
Debug: Executing '/bin/systemctl is-enabled puppet'
Debug: Executing '/bin/systemctl start puppet'
Error: Could not start Service[puppet]: Execution of '/bin/systemctl start
puppet' returned 6:
Error: /Stage[main]/Sys_puppet_agent/Service[puppet]/ensure: change from
stopped to running failed: Could not start Service[puppet]: Execution of
'/bin/systemctl start puppet' returned 6:
Puppet should be managed under systemd scripts as soon as possible (like every
other services on fedora 18).
I can help too if you have suggestions,
Vincent Gallissot
NB : my top directive to make systemd default for fedora>=18 :
case $operatingsystem {
'Fedora': { if $operatingsystemrelease >= 18 {
Service{
provider => 'systemd'
}
notify { "on change le provider vers systemd": }
}
}
}
and a service example :
service { sshd:
ensure => running,
hasrestart => true,
enable => true,
require => File['/etc/ssh/sshd_config']
}
}
----------------------------------------
Feature #15911: automatic .service suffix for the systemd provider to keep
service names consistent
https://projects.puppetlabs.com/issues/15911#change-84185
Author: Robert Kennedy
Status: Needs More Information
Priority: Normal
Assignee: Charlie Sharpsteen
Category: service
Target version:
Affected Puppet version:
Keywords: systemd
Branch:
I'd like to be able to be able to have a mix of systemd and redhat systems that
run the same named services. Currently it seems I have to resort to
<pre>
$snmpservicename = $snmpserviceprovider ? {
"systemd" => "snmpd.service",
"redhat" => "snmpd",
}
service { "$snmpservicename":
provider => "$snmpserviceprovider",
etc.
}
</pre>
I would much rather choose the provider for my system and be able to refer to
the snmpd service with the same name across hosts with different providers if
possible. I believe everything that puppet would want to handle as a Service
would have a .service suffix. If you think it would cause too much confusion
due to the assumption of service naming, I can continue to do what I'm doing.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
