Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-4545

Too many restarts on interface changes for Fedora, RHEL, CentOS

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 3.7.5
    • Fix Version/s: PUP 3.8.7
    • Component/s: None
    • Labels:
    • Template:
    • Story Points:
      2
    • Sprint:
      RE 2015-07-29, RE 2015-08-26, RE 2015-09-09, Client 2016-05-04
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      Remove a script that restarts puppet in response to network changes on EL based systems. It was causing pain in containers and other systems where network restarts are common and frequent.
      If users have frequent system reboots combined with slow DHCP responses, they may want to add the script back to ensure that their agent is able to connect with their puppetmaster.
      Show
      Remove a script that restarts puppet in response to network changes on EL based systems. It was causing pain in containers and other systems where network restarts are common and frequent. If users have frequent system reboots combined with slow DHCP responses, they may want to add the script back to ensure that their agent is able to connect with their puppetmaster.

      Description

      In https://projects.puppetlabs.com/issues/2776 a workaround was introduced to restart puppet on Fedora, RHEL, CentOS which restarts puppet on each interface change. The script /etc/NetworkManager/dispatcher.d/98-puppet restarts puppet agents every time a interface goes up or down regardless of the type.
      Nowadays with VMs and containers you can get a lot of interface up downs for virtual interfaces. Because of the workaround from #2776 this creates a lot of un-necessary agent restarts.

      A workaround of the workaround might be to make a regex blacklist for interface names, e.G. [ 'veht.', 'vibr.', 'docker.*']
      A cleaner solution would be to actually monitor /etc/resolv.conf in an agent run, since changes in resolv.conf by agent was the original problem, and not to use NetworkManager for restarts.

        Attachments

          Activity

            jsd-sla-details-panel

              People

              • Assignee:
                Unassigned
                Reporter:
                TheMeier Christoph Maser
              • Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support