Bug 240566 - devel/leatherman: Breaks sysutils/facter with the default lang/ruby changing to 2.6
Summary: devel/leatherman: Breaks sysutils/facter with the default lang/ruby changing ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: FreeBSD Puppet Team
URL:
Keywords: needs-qa, regression
Depends on:
Blocks:
 
Reported: 2019-09-13 14:20 UTC by albert.shih
Modified: 2019-09-23 21:17 UTC (History)
3 users (show)

See Also:
romain: maintainer-feedback+


Attachments
Patch to fix leatherman (1.96 KB, patch)
2019-09-14 03:21 UTC, Allan Jude
romain: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description albert.shih 2019-09-13 14:20:43 UTC
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
Comment 1 Romain Tartière freebsd_committer 2019-09-13 16:48:59 UTC
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 ~ %
Comment 2 Allan Jude freebsd_committer 2019-09-14 03:11:41 UTC
(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.
Comment 3 Allan Jude freebsd_committer 2019-09-14 03:21:06 UTC
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.
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-14 04:38:21 UTC
Are quarterly versions affected? If so please set merge-quarterly
Comment 5 Romain Tartière freebsd_committer 2019-09-14 05:29:09 UTC
Wow, thanks for the fast analysis and solution Allan!

I put on my puppet@ hat to approve this change!
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-14 06:42:24 UTC
@Romain Set maintainer-approval flag (to +) on attachments to signify maintainer approval. Attachment -> Details -> maintainer-approval [+]
Comment 7 commit-hook freebsd_committer 2019-09-14 16:30:08 UTC
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
Comment 8 Romain Tartière freebsd_committer 2019-09-14 16:37:00 UTC
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!
Comment 9 Athanasios Douitsis 2019-09-14 16:39:20 UTC
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.
Comment 10 Athanasios Douitsis 2019-09-14 16:47:59 UTC
(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.
Comment 11 Athanasios Douitsis 2019-09-14 16:54:11 UTC
(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.
Comment 12 Romain Tartière freebsd_committer 2019-09-23 21:17:57 UTC
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!