Issue #2899 has been updated by Brice Figureau.
Josh Endries wrote: > We stumbled upon a puppetd using 100% CPU and 12 GB of RAM a few days ago. We > have a DB app in /usr/local/fedora and a dev was doing work on migrating to a > new version and had many files in /usr/local/fedora/migration. We copy > /usr/local/fedora recursively from puppetmaster, so it (something) does > descend into the folder, but /usr/local/fedora/migration is not part of those > files. Nevertheless, the client's puppetd seemed to descend into it, probably > doing checksums or something, and ran for possibly days eating up more and > more RAM and constant high CPU. We worked around it by shutting puppetd down > until the migration is finished. /usr/local/fedora/migration is below /usr/local/fedora. Using recurse => true, will recurse on *both* side (ie source and destination), so the behaviour you are observing is correct. Use: @recurse => remote@ to recurse only on the server side (ignoring everything that is already on your client). You should also be aware that recursing locally on a directory involves md5 checksumming every file which is costly (see #2929). ---------------------------------------- Bug #2899: puppetd checks client files recursively even if they aren't specified http://projects.reductivelabs.com/issues/2899 Author: Josh Endries Status: Investigating Priority: Normal Assigned to: Jesse Wolfe Category: fileserving Target version: 0.25.5 Affected version: 0.25.1 Keywords: Branch: We stumbled upon a puppetd using 100% CPU and 12 GB of RAM a few days ago. We have a DB app in /usr/local/fedora and a dev was doing work on migrating to a new version and had many files in /usr/local/fedora/migration. We copy /usr/local/fedora recursively from puppetmaster, so it (something) does descend into the folder, but /usr/local/fedora/migration is not part of those files. Nevertheless, the client's puppetd seemed to descend into it, probably doing checksums or something, and ran for possibly days eating up more and more RAM and constant high CPU. We worked around it by shutting puppetd down until the migration is finished. This may be worked around by using an ignore statement, I haven't tested that since this situation is temporary, but that requires you know where the files will be placed beforehand. This seems to suggest a DoS could be done against Puppet or the system pretty easily by putting a directory somewhere with tons of files in it, if Puppet copies the parent recursively. It also generally seems like a bad design, the client reading things in that the server doesn't need a check for, but maybe isn't easy to fix. Anyway, I think it should be discussed or at least brought to attention. :) I may be able to set up a test environment if necessary. -- 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://reductivelabs.com/redmine/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
