Jira (FACT-2055) Facter fails if its working directory does not exist

[John Bollinger (JIRA)]

John Bollinger created an issue

Facter / FACT-2055 Facter fails if its working directory does not exist Issue Type: Bug Affects Versions: FACT 3.14.3 Assignee: Unassigned Components: CLI Created: 2019/10/03 12:00 PM Priority: Minor Reporter: John Bollinger Originally reported as part of PUP-10080: puppet fails if its working directory does not exist.  Josh Cooper attributes the failure to Facter, and indeed, the standalone facter executable seems to exhibit related behavior. All puppet faces seem to be affected, including those that have no plausible need for working-directory access, such as puppet help. Facter does not exhibit such a failure when the working directory exists but is inaccessible to it. Expected behavior When its working directory does not exist, facter should nevertheless run successfully and evaluate and report all the facts it can do. This should happen for both the standalone executable and for the Puppet-integrated version. Observed behavior Facter crashes immediately when its working directory does not exist. For the puppet-integrated version, this crashes the whole puppet process. To reproduce 1. Create a fresh directory for the experiment: mkdir doomed. 2. Make that directory the working directory: cd doomed. 3. In a separate shell, remove the directory: rm doomed. 4. In the first shell, run facter or any Puppet command at all, for example facter or puppet facts or even puppet help The Puppet output under these circumstances is shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::current_path: No such file or directory Aborted The output of the standalone facter executable is similar: shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory 2019-10-03 13:35:14.747025 FATAL puppetlabs.facter - unhandled exception: boost::filesystem::current_path: No such file or directory Of course, the natural workaround is to run puppet and / or facter from an existing working directory. Doing otherwise unintentionally is unlikely in typical environments. Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[James Ralston (JIRA)]

James Ralston commented on FACT-2055

Re: Facter fails if its working directory does not exist The problem is that although facter does not call boost::filesystem::current_path directly (at least as far as I can tell), something else it calls does (most likely, another boost library call), and getcwd() fails with ENOENT if the cwd has been unlinked. I'll play devil's advocate here: is this a bug with Puppet, or a feature of Unix? Puppet is not the only program that will fail if its cwd is unlinked. A great many number of standard Unix utilities will throw errors (and potentially die / fail to function) if the cwd does not exist. If facter died or produced errors if the cwd were inaccessible, I would assert that is a bug with facter. (See PUP-9997 for the rationale there.) But facter bombing out if its cwd is unlinked? I'd argue the most reasonable response to that might simply be the punchline to the old "doctor, it hurts when I move my arm this way" joke: then don't do that.

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on FACT-2055

Re: Facter fails if its working directory does not exist

I'm not sure about the "great many" Unix utilities that fail if the working directory is unlinked, James Ralston.  Of the several that I selected for testing on a CentOS 7 system, the only one that failed was Bash, and even Bash ran successfully (albeit after emitting a warning) when launched as /bin/sh – both interactively and non-interactively. No other that I tested even warned.  Ruby (irb), Python, and Perl were all ok. Sed was ok. /bin/cat was ok. Even /bin/ls with no arguments just silently emitted a completely empty listing. Thus, no, I don't think it's reasonable to characterize this as a Unix feature. Moreover, since I can't come up with anything that the Facter core ought to be doing that would require working-directory access, yes, it is a bug in Facter. Whether it is a bug that should be fixed is a different question. I know I can come up with scenarios where the faulty behavior is a genuine real-world problem, but it remains to be seen how contrived they would end up being. I am imagining applications in highly dynamic environments where "don't do that" is not a viable alternative.  Nevertheless, I discovered this issue while trying to reproduce and characterize the inaccessible working directory case originally reported in PUP-10080. My own uses of Puppet do not ordinarily run into the unlinked working directory issue.

Add Comment