Uploaded image for project: 'Facter'
  1. Facter
  2. FACT-1992

autofs mountpoints being mounted by facter

    Details

    • Template:
    • Acceptance Criteria:
      Hide

      Running facter does not trigger autofs automounts to become mounted.

      Show
      Running facter does not trigger autofs automounts to become mounted.
    • Team:
      Night's Watch
    • Story Points:
      3
    • Sprint:
      NW - 2019-09-18
    • Method Found:
      Needs Assessment
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      Hide
      When Facter stats a mountpoint to get the size and available space, it causes mountpoints of type {{autofs}} to be automatically mounted, which is not the intended behavior.

      Automounts are now skipped by Facter when resolving mountpoints.
      Show
      When Facter stats a mountpoint to get the size and available space, it causes mountpoints of type {{autofs}} to be automatically mounted, which is not the intended behavior. Automounts are now skipped by Facter when resolving mountpoints.
    • QA Risk Assessment:
      Needs Assessment

      Description

      After updating to facter 3.11.9 we started experiencing issues caused by the regular mounting and unmounting of automount filesystems. We traced the cause back to facter and found that it was triggering a mount of . This seems to be related to the change made in FACT-1910 (0f0d8f4df70f886ec7ae86f65a24909a4f20b0f7/lib/src/facts/linux/filesystem_resolver.cc). The auto mount is triggered by stating the mount dir to get the size and available space.

      Skipping non-physical mountpoints was a good catch all of a lot of synthetic filesystems which could introduce other problems problems and so it seems it will now be required to maintain a list of mount types to ignore.

      The change should be reverted, autofs should be added as a skipped mtype (as with tempfs) or you should not stat autofs mountpoints.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                gabriel.nagy Gabriel Nagy
                Reporter:
                qcfabrizio Fabrizio Lungo
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support

                    Time Tracking

                    Estimated:
                    Original Estimate - 1 hour
                    1h
                    Remaining:
                    Remaining Estimate - 1 hour
                    1h
                    Logged:
                    Time Spent - Not Specified
                    Not Specified