Hi, I'm not 100% sure the problem are come from facter, because even if I use a lot puppet/facter I'm not very aware of the code himself. I event don't have any idea if the problem come from ruby or facter. Anyway between facter-3.14.3/Ruby-2.5 and facter-3.14.3/ruby-2.6 we lost some legacy variable. With ruby 2.6 [root@filer]# facter --show-legacy|grep ^opera operatingsystem => FreeBSD [root@file]# facter --version 3.14.3 [root@filer]# ruby --version ruby 2.6.4p104 (2019-08-28 revision 67798) [amd64-freebsd12] with ruby2.5 [root@filer]# facter --show-legacy|grep ^opera operatingsystem => FreeBSD operatingsystemmajrelease => 12 operatingsystemrelease => 12.0-RELEASE-p9 [root@filer]# facter --version 3.14.3 [root@filer]# ruby --version ruby 2.5.6p201 (2019-08-28 revision 67796) [amd64-freebsd12] [root@filer]# I can understand legacy variable will some day goes away, but because facter version did't change I will say it's not normal. I've no idea when the legacy variable will be remove but currently (modules are mainly from puppetlabs) [root @ modules]$ find . -type f -name "*.pp" -exec grep -l operatingsystemmajrelease {} \;|wc 35 35 1171 So...no close to be remove Regards
Can reproduce the problem: romain@zappy ~ % facter --show-legacy|grep ^opera operatingsystem => FreeBSD operatingsystemmajrelease => 12 operatingsystemrelease => 12.0-RELEASE-p10 romain@zappy ~ % facter os { architecture => "amd64", family => "FreeBSD", hardware => "amd64", name => "FreeBSD", release => { full => "12.0-RELEASE-p10", major => "12", minor => "0-RELEASE-p10" } } romain@zappy ~ % facter --version 3.14.3 romain@zappy ~ % ruby --version ruby 2.5.6p201 (2019-08-28 revision 67796) [amd64-freebsd12] romain@zappy ~ % After update: romain@zappy ~ % facter --show-legacy|grep ^opera operatingsystem => FreeBSD romain@zappy ~ % facter os { architecture => "amd64", family => "FreeBSD", hardware => "amd64", name => "FreeBSD" } romain@zappy ~ % ruby --version ruby 2.6.4p104 (2019-08-28 revision 67798) [amd64-freebsd12] romain@zappy ~ %
(In reply to Romain Tartière from comment #1) After some investigation, I've figured this out. First strange thing: it works if run under truss... # facter operatingsystemrelease # truss -c facter operatingsystemrelease 12.0-RELEASE syscall seconds calls errors ...<snip>... when run with --debug (with uninteresting output snipped): # facter --debug operatingsystemrelease 2019-09-14 03:08:35.376624 INFO puppetlabs.facter - executed with command line: --debug operatingsystemrelease. 2019-09-14 03:08:35.378074 DEBUG leatherman.ruby:513 - ruby was found at "/usr/local/bin/ruby". 2019-09-14 03:08:35.649078 INFO leatherman.ruby:195 - using ruby version 2.6.4 2019-09-14 03:08:35.649280 INFO puppetlabs.facter - requested queries: operatingsystemrelease. 2019-09-14 03:08:35.649501 DEBUG puppetlabs.facter - fact "facterversion" has resolved to "3.14.3". 2019-09-14 03:08:35.652908 DEBUG puppetlabs.facter - fact "kernel" has resolved to "FreeBSD". 2019-09-14 03:08:35.652970 DEBUG puppetlabs.facter - fact "kernelrelease" has resolved to "13.0-CURRENT". 2019-09-14 03:08:35.653024 DEBUG puppetlabs.facter - fact "kernelmajversion" has resolved to "13". 2019-09-14 03:08:35.653074 DEBUG puppetlabs.facter - fact "kernelversion" has resolved to "13.0". 2019-09-14 03:08:35.653207 DEBUG leatherman.execution:93 - executing command: /bin/freebsd-version 2019-09-14 03:08:35.655812 DEBUG | - 12.0-RELEASE 2019-09-14 03:08:35.656474 DEBUG leatherman.execution:491 - waitpid failed: Interrupted system call (4). 2019-09-14 03:08:35.656548 DEBUG leatherman.execution:563 - process exited with status code 0. 2019-09-14 03:08:35.656629 DEBUG puppetlabs.facter - fact "osfamily" has resolved to "FreeBSD". 2019-09-14 03:08:35.656700 DEBUG puppetlabs.facter - fact "hardwaremodel" has resolved to "amd64". 2019-09-14 03:08:35.656757 DEBUG puppetlabs.facter - fact "architecture" has resolved to "amd64". 2019-09-14 03:08:35.656811 DEBUG puppetlabs.facter - fact "operatingsystem" has resolved to "FreeBSD". 2019-09-14 03:08:35.656877 DEBUG puppetlabs.facter - fact "os" has resolved to { architecture => "amd64", family => "FreeBSD", hardware => "amd64", name => "FreeBSD" }. 2019-09-14 03:08:35.656989 DEBUG puppetlabs.facter - fact "operatingsystemrelease" does not exist. So I tracked the problem down to an upstream pull request from a few hours ago: https://github.com/puppetlabs/leatherman/pull/305 And have prepared a patch for our port until the next release and confirmed it works: And now when run under debug, it says: 2019-09-14 03:10:49.412763 DEBUG leatherman.execution:93 - executing command: /bin/freebsd-version 2019-09-14 03:10:49.415164 DEBUG | - 12.0-RELEASE 2019-09-14 03:10:49.415736 DEBUG leatherman.execution:492 - waitpid was interrupted by a signal, retrying: Interrupted system call (4). 2019-09-14 03:10:49.415823 DEBUG leatherman.execution:568 - process exited with status code 0. 2019-09-14 03:10:49.415902 DEBUG puppetlabs.facter - fact "osfamily" has resolved to "FreeBSD". 2019-09-14 03:10:49.415995 DEBUG puppetlabs.facter - fact "operatingsystemmajrelease" has resolved to "12". 2019-09-14 03:10:49.416050 DEBUG puppetlabs.facter - fact "operatingsystemrelease" has resolved to "12.0-RELEASE". 2019-09-14 03:10:49.416105 DEBUG puppetlabs.facter - fact "hardwaremodel" has resolved to "amd64". 2019-09-14 03:10:49.416153 DEBUG puppetlabs.facter - fact "architecture" has resolved to "amd64". 2019-09-14 03:10:49.416203 DEBUG puppetlabs.facter - fact "operatingsystem" has resolved to "FreeBSD". 2019-09-14 03:10:49.416270 DEBUG puppetlabs.facter - fact "os" has resolved to { architecture => "amd64", family => "FreeBSD", hardware => "amd64", name => "FreeBSD", release => { full => "12.0-RELEASE", major => "12", minor => "0-RELEASE" } }. 12.0-RELEASE And works as expected.
Created attachment 207481 [details] Patch to fix leatherman This patch resolves the issue with puppet/facter not being able to get facts that involve executing a process (like freebsd-version). It looks like it will be fixed upstream in the next version.
Are quarterly versions affected? If so please set merge-quarterly
Wow, thanks for the fast analysis and solution Allan! I put on my puppet@ hat to approve this change!
@Romain Set maintainer-approval flag (to +) on attachments to signify maintainer approval. Attachment -> Details -> maintainer-approval [+]
A commit references this bug: Author: romain Date: Sat Sep 14 16:29:23 UTC 2019 New revision: 512035 URL: https://svnweb.freebsd.org/changeset/ports/512035 Log: Fix execution interupted by signal detection With the default version of Ruby changing to 2.6, sysutils/facter fails to gather some facts due to leatherman not handling signals properly. With hat: puppet PR: 240566 Submitted by: allanjude Reported by: albert.shih@obspm.fr Changes: head/devel/leatherman/Makefile head/devel/leatherman/files/patch-execution_src_posix_execution.cc
koobs@, I am not sure about the quarterly branches: for now they all default to previous version of Ruby which did not show the problem. I believe this problem is shown only when using Ruby 2.6. Because when the quarterly branches will default to Ruby 2.6 leatherman will have the proper patch, I believe there is nothing more to do… Please correct me if I am wrong :-) Thanks!
Patch author here, saw your comment on github Alan. I'm delighted it proves to be useful to others, I was under the impression I'm the only soul on the planet using puppet on FreeBSD. Please note that the bug was detected on FreeBSD and dwatch/dtrace proved to be immensely useful in figuring it out with relative ease.
(In reply to Romain Tartière from comment #8) The problem is not related to Ruby, since this is the Facter that is written in C++. Don't know the exact point in time it was introduced though.
(In reply to Romain Tartière from comment #8) In case my previous comment came across the wrong way, I was only trying to clarify. You are of course correct, by the time the quarterly switches, the leatherman bug will be sorted.
i have been running with the fix for some time and got no wrong feedback, so I guess we can close this. Thanks for your help with fixing this!