Jira (FACT-2682) facter -p returns NUL character on stdout when called from nested ruby on windows

[David Schmitt (Jira)]

Title: Message Title

David Schmitt created an issue   Facter / FACT-2682 facter -p returns NUL character on stdout when called from nested ruby on windows Issue Type: Bug Assignee: Unassigned Components: Windows Created: 2020/06/24 12:15 PM Environment: Personally reproduced with puppet 6.16.0, facter 3.14.11 (commit ed6c9052b125bee55f21f43d55f790c08ec75c1c), windows server 2019 (gusztavvargadr/windows-server) as well as the hydra demo environment. See the linked tickets for more tangential reproduction environments going back to 2019.2.1. Priority: Normal Reporter: David Schmitt As result of the investigation into MODULES-10602 and FM-8887, it was found that facter misbehaves on windows when being called from another ruby process while at the same time also executing other processes: When deploying the following fact to C:\ProgramData\PuppetLabs\puppet\cache\lib\facter\debugg.rb Facter.add(:debugg) do setcode do puts `cmd /c echo bar`.inspect end end weird things start to happen: PS C:\> & 'C:\Program Files\Puppet Labs\Puppet\puppet\bin\irb.bat' irb(main):001:0> `facter -p debugg` => "\x00\"bar\\n\"\n" irb(main):002:0> Note the \x00 at the start of the output. Replacing the backtick-call to cmd in the fact with a regular string makes the behaviour go away: Facter.add(:debugg) do setcode do puts "bar\n".inspect end end irb(main):002:0> `facter -p debugg` => "\n\"bar\\n\"\n" irb(main):003:0> Curiously, using Puppet::Util::Execution.execute for calling facter also does not show the issue: irb(main):004:0> Puppet::Util::Execution.execute("facter -p debugg") => "\n\"bar\\n\"\n" irb(main):005:0> I could verify that this is the cause for the behaviour seen in MODULES-10602 and FM-8887, and I could reproduce it with only the latest puppet-agent (6.16.0) installed on a windows server 2019 virtual box (gusztavvargadr/windows-server). Customers and SEs have reported seeing the same symptoms as far back as 2019.2.1. For a full-featured repro environment, the hydra demo environments work out of the box, as (amongst others) the chocolateyversion fact triggers the bug. I could not reproduce it on a litmusimage/centos:8 docker image with the same agent version: david@zion:~/git/puppetlabs-motd (master)$ docker exec -ti litmusimage_centos_8-2225 /bin/bash [root@40541a36d2a8 /]# cat /opt/puppetlabs/puppet/cache/lib/facter/debugg.rb Facter.add(:debugg) do setcode do #puts `cmd /c echo bar`.inspect puts `echo bar`.inspect end end [root@40541a36d2a8 /]# /opt/puppetlabs/puppet/bin/irb irb(main):001:0> `facter -p debugg` => "\n\"bar\\n\"\n" irb(main):002:0> exit [root@40541a36d2a8 /]# puppet --version 6.16.0 [root@40541a36d2a8 /]# https://github.com/puppetlabs/puppetlabs-facter_task/pull/125 has a workaround for the facter_task task. Since it is neither a straight up functional equivalent, nor keeps other tasks from breaking, I'm hesitant to commit that PR as a "fix" for this issue. See https://puppet.slack.com/archives/CF418R4BE/p1592905228073600 for extensive just-in-time debugging log. Add Comment   This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.363822.1593026104000.94636.1593026160192%40Atlassian.JIRA.