Passing the base directory seems to fix the problem, but that keyword argument was added in ruby 2.5 and facter 4 supports 2.3 and up. So probably need to do:
Facter's gemspec globs "bin" and "lib" relative to the current working directory when the gem is activated. When puppet is running as a service, its cwd is "/", which results in the ruby process globbing /bin and /lib, leading to ~45k more : {noformat}[root@velvety-hybrid /]# cd /root [root@velvety-hybrid ~]# strace -fc -e newfstatat /opt/puppetlabs/puppet/bin/ruby -e 'Gem::Specification.load("/opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/specifications/facter-4.1.0.gemspec")' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000046 0 49 1 newfstatat ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000046 49 1 total [root@velvety-hybrid ~]# cd / [root@velvety-hybrid /]# strace -fc -e newfstatat /opt/puppetlabs/puppet/bin/ruby -e 'Gem::Specification.load("/opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/specifications/facter-4.1.0.gemspec")' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.155833 3 46513 1 newfstatat ------ ----------- ----------- --------- --------- ---------------- 100.00 0.155833 46513 1 total {noformat}
Evaluation times of maually running _puppet agent -t_ and running automatically via service are different.
If manually, I see in reports total 25s and 5s for _file_ category. Via service - total 120s and 90s of them for _file_.
I made strace of puppet when running automatically and noticed that it's workdir is / and puppet somewhy recursievely reading files in all folders, for example, kernel firmware modules: {code:java} 231809 12:54:12 openat(AT_FDCWD, "lib/modules/3.10.0-962.3.2.lve1.5.28.el7.x86_64/kernel/drivers/firmware", O_RDONLY|O_CLOEXEC|O_DIRECTORY) = 12 {code} Nothing like that with manual run.
When I added parameter in /usr/lib/systemd/system/puppet.service {code:java} WorkingDirectory=/opt/puppetlabs/puppet/bin/{code} evaluation time reduced notably and became also 25s in total.
*Desired Behavior:*
Maybe WorkingDirectory in service file should be defined and puppet agent packaged with it?
*Actual Behavior:*
My workaround is not permanent for the moment because puppet.service overwrites during puppet-agent package updates.
Facter's gemspec globs "bin" and "lib" relative to the current working directory when the gem is activated. When puppet is running as a service, its cwd is "/", which results in the ruby process globbing /bin and /lib, leading to ~45k more :
100.00 0.155833 46513 1173795 53589 206 total {noformat}
h3. *Original*
*Puppet Version: 7.7.0*
*OS Name/Version: CentOS 7 (with CloudLinux)*
Evaluation times of maually running _puppet agent -t_ and running automatically via service are different.
If manually, I see in reports total 25s and 5s for _file_ category. Via service - total 120s and 90s of them for _file_.
I made strace of puppet when running automatically and noticed that it's workdir is / and puppet somewhy recursievely reading files in all folders, for example, kernel firmware modules: {code:java}231809 12:54:12 openat(AT_FDCWD, "lib/modules/3.10.0-962.3.2.lve1.5.28.el7.x86_64/kernel/drivers/firmware", O_RDONLY|O_CLOEXEC|O_DIRECTORY) = 12 {code} Nothing like that with manual run.
When I added parameter in /usr/lib/systemd/system/puppet.service {code:java}WorkingDirectory=/opt/puppetlabs/puppet/bin/{code} evaluation time reduced notably and became also 25s in total.
*Desired Behavior:*
Maybe WorkingDirectory in service file should be defined and puppet agent packaged with it?
*Actual Behavior:*
My workaround is not permanent for the moment because puppet.service overwrites during puppet-agent package updates.
Facter's gemspec globs "bin" and "lib" relative to the current working directory when the gem is activated. When puppet is running as a service, its cwd is "/", which results in the ruby process globbing /bin and /lib, leading to ~45k53k more file syscalls. This process repeats for each REST request, due to puppet checking to see if the msgpack feature is present : {noformat}[root@velvety-hybrid ~]# cd /root/ [root@velvety-hybrid ~]# strace -fc -e trace=file /opt/puppetlabs/puppet/bin/ruby -e 'Gem::Specification.load("/opt/puppetlabs/puppet/lib/ruby/gems/2.7.0/specifications/facter-4.1.0.gemspec")'
Evaluation times of maually running _puppet agent -t_ and running automatically via service are different.
If manually, I see in reports total 25s and 5s for _file_ category. Via service - total 120s and 90s of them for _file_.
I made strace of puppet when running automatically and noticed that it's workdir is / and puppet somewhy recursievely reading files in all folders, for example, kernel firmware modules: {code:java}231809 12:54:12 openat(AT_FDCWD, "lib/modules/3.10.0-962.3.2.lve1.5.28.el7.x86_64/kernel/drivers/firmware", O_RDONLY|O_CLOEXEC|O_DIRECTORY) = 12 {code} Nothing like that with manual run.
When I added parameter in /usr/lib/systemd/system/puppet.service {code:java}WorkingDirectory=/opt/puppetlabs/puppet/bin/{code} evaluation time reduced notably and became also 25s in total.
*Desired Behavior:*
Maybe WorkingDirectory in service file should be defined and puppet agent packaged with it?
*Actual Behavior:*
My workaround is not permanent for the moment because puppet.service overwrites during puppet-agent package updates.
Facter recursively scanned the "bin" and "lib" directories relative to the current working directory when it was loaded. When "puppet" runs a service, the current working directory is "/" so we were scanning all of "/lib". Now we only scan directories relative to the location of Facter's gemspec.