[PUP-1200] [meta] please stop arbitrarily changing systemd service unit names
Created: 2013/12/20 Updated: 2014/02/17
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Reopened
Puppet
None
PUP 3.4.0
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Improvement
Sam Kottler
Unresolved
systemd
Not Specified
Issue Links:
Blocks
is blocked by PUP-1463 Ensure services that were previously ...
Relates
relates to
PUP-1463 Ensure services that were previously ...
Template:
None
Priority:
Assignee:
Votes:
Normal
Sam Kottler
0
Not Specified
Not Specified
Closed
Closed
customfield_10700 true
Description
In 3.4, what was previously puppetagent.service is now puppet.service. Now every person who
was managing the puppet service and used systemd has to add a case statement based on
version. I understand that puppet is a better (and more consistent) name, but the change seems
unfounded. Instead of fixing any problem it just introduces yet another complexity in end-user
interaction with packaged versions of puppet.
Comments
Comment by Sam Kottler [ 2013/12/20 ]
Also, I'm considering installing puppet.service as puppetagent.service in the official Fedora
packages. Can we agree to do that in the PL packages, too?
Comment by Michael Stahnke [ 2013/12/20 ]
Matthaus Owens and Moses Mendoza can you weigh in here?
Comment by Moses Mendoza [ 2013/12/20 ]
What was originally a service called 'puppet' was unfortunately renamed to 'puppetagent' in our
systemd files around the time we shipped them for the first time (see
http://projects.puppetlabs.com/issues/16144 and https://projects.puppetlabs.com/issues/22660).
We decided then to go back to calling it 'puppet.service' for historical consistency, and
symlinking puppetagent.service to puppet.service. So in 3.4.0 rpms, we ship both puppet.service
and puppetagent.service. For me doing both
systemctl status puppet
and
systemcl status puppetagent
works fine. Sam Kottler is this not the case for you?
Comment by Sam Kottler [ 2013/12/21 ]
I just did another installation and the symlink is working properly; I've got one agent running
and both service names work when using systemctl. Not exactly sure why that didn't work when
I was testing yesterday.
Thanks a bunch and sorry for unnecessarily raising the ticket. I really appreciate the work you
all do and have a great holiday season!
Comment by Dominic Cleal [ 2014/01/15 ]
Sorry for re-opening this, but one issue with the symlink appears to be that systemctl enable
throws an error when trying to enable it at boot. For example:
[root@foreman-f19 ~]# rpm -q puppet
puppet-3.4.2-1.fc19.noarch
[root@foreman-f19 ~]# systemctl status puppet.service
puppetagent.service
puppet.service - Puppet agent
Loaded: loaded (/usr/lib/systemd/system/puppet.service;
disabled)
Active: inactive (dead)
puppet.service - Puppet agent
Loaded: loaded (/usr/lib/systemd/system/puppet.service;
disabled)
Active: inactive (dead)
[root@foreman-f19 ~]# systemctl enable puppetagent.service
Failed to issue method call: No such file or directory
[root@foreman-f19 ~]# systemctl enable puppet.service
ln -s '/usr/lib/systemd/system/puppet.service'
'/etc/systemd/system/multi-user.target.wants/puppet.service'
systemctl start/stop appear to work normally though.
Just trying to figure out at the moment how to support this and the package in Fedora itself,
which doesn't have this change yet.
Comment by Sam Kottler [ 2014/01/15 ]
I think ultimately the fix needs to happen in systemd because there is currently a clear
inconsistency between the way it handles different actions on symlinked (aliased?) service units.
In the meantime we should provide an upgrade path that disables the puppetagent service in
%preun and enables the puppet service in %postun perhaps? That'll still bite people who
manage the agent with Puppet, but at least they'll get an error instead of silent failure when the
agent doesn't start on boot.
Comment by Dominic Cleal [ 2014/01/16 ]
It appears the systemd behaviour is desired, they don't want to allow 'enable' to operate on
symlinks:
https://bugzilla.redhat.com/show_bug.cgi?id=955379 (c14 in particular)
Comment by John Florian [ 2014/02/14 ]
This is most frustrating. Can somebody here please post the specific change points? I
unfortunately have to support clients that may not get updated (for change control reasons). This
constant, silly renaming is nothing but grief. "Historical consistency" would have been to never
change it and if it did get changed and released to leave the problem alone and not make it
worse as was done. These types of things shouldn't be changing without extremely good
justification. Every time this sort of thing happens, puppet looses some of its value in reducing
burden.
Presently, I'm now operating with the following. This was a PITA to arrive at because 3.1.1 on
F19 has "puppetagent" through systemd whereas 3.1.1 on F18 has only "puppet" via init.d.
case $::operatingsystem {
Fedora: {
if $::operatingsystemrelease >= 19 and
versioncmp($puppetversion, '3.1.1') >= 0 and
versioncmp($puppetversion, '3.4.0') < 0 {
$client_service_name = 'puppetagent'
} else {
$client_service_name = 'puppet'
}
}
}
Generated at Tue Feb 09 10:11:57 PST 2016 using JIRA 6.4.12#64027sha1:e3691cc1283c0f3cef6d65d3ea82d47743692b57.