[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.