Jira (PUP-10080) Exec resources fail if the working directory is inaccessible

[John Bollinger (JIRA)]

John Bollinger created an issue

Puppet / PUP-10080 Exec resources fail if the working directory is inaccessible Issue Type: Bug Affects Versions: PUP 6.8.1 Assignee: Unassigned Components: Types and Providers, UX Created: 2019/10/03 8:15 AM Priority: Minor Reporter: John Bollinger Puppet Version: 6.8.1 Puppet Server Version: 6.5.0 OS Name/Version: CentOS 7 Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist. I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I sudo a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple Exec resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the Exec should fail. Desired Behavior: Exec resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the cwd parameter. Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason. Actual Behavior: Exec resources spuriously fail when the working directory cannot be accessed, even when no particular working directory is specified, and even when execution of the command does not depend on accessing the working directory. The specific failure mode seems to depend on details of the situation, but the one I normally run into can be reproduced with puppet apply, too, like so: Example 1 1. log in to a machine on which my home directory is on an automounted NFS file system with root squashing in effect 2. sudo bash to obtain a root shell 3. Execute puppet apply --execute "exec { '/bin/echo': }" Output: Notice: Compiled catalog for moby.stjude.org in environment production in 0.04 seconds Error: Working directory /mnt/auto/home/miller2grp/jbolling does not exist! Error: /Stage[main]/Main/Exec[/bin/echo]/returns: change from 'notrun' to ['0'] failed: Working directory /mnt/auto/home/miller2grp/jbolling does not exist! Notice: Applied catalog in 0.12 seconds Errors of the same form are also reported by the agent under these circumstances if the catalog being applied contains `Exec` resources without cwd parameters. On the other hand, these particular failures do not occur if the Exec in question has a cwd parameter designating an existing, accessible directory, notwithstanding that the Puppet process's own working directory is inaccessible to it. Oddly enough, a different failure occurs if Puppet's working directory actually doesn't exist. That situation can be reproduced like so: Example 2 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 any Puppet command at all, for example puppet agent --test or puppet apply --execute "exec { '/bin/echo': cwd => '/tmp' }" . Output 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 As described in conjunction with Example 1, however, Puppet does not actually need to access the current working directory to compile or apply a catalog, at least not as a general rule, so this failure is spurious. Of course, these issues can be worked around by ensuring that the working directory is an existing, accessible one before running Puppet, and I imagine that both failure scenarios presented are unlikely for most people. However, I personally hit the Example 1 case often enough to inspire me to file this report. I note also that it's distinctly more annoying when it occurs as a result of puppet agent --test ing a catalog that takes a minute to retrieve and a few minutes to apply, and there is some risk that such a failure leaves the system in an unexpected state requiring manual intervention. Add Comment

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

[John Bollinger (JIRA)]

John Bollinger updated an issue

Puppet / PUP-10080 Exec resources fail if the working directory is inaccessible

Change By: John Bollinger *Puppet Version:* 6.8.1 *Puppet Server Version:* 6.5.0 *OS Name/Version:* CentOS 7

Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist. I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I {{sudo}} a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple {{Exec}} resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the {{Exec}} should fail.

*Desired Behavior:* {{Exec}} resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the {{cwd}} parameter.

Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason.

*Actual Behavior:* {{Exec}} resources spuriously fail when the working directory cannot be accessed, even when no particular working directory is specified, and even when execution of the command does not depend on accessing the working directory. The specific failure mode seems to depend on details of the situation, but the one I normally run into can be reproduced with {{puppet apply}}, too, like so: ---- *Example 1*

1. log in to a machine on which my home directory is on an automounted NFS file system with root squashing in effect 2. {{sudo bash}} to obtain a root shell 3. Execute

{code:shell}puppet apply --execute "exec { '/bin/echo': }"{code} *_Output:_* {quote}Notice: Compiled catalog for moby xxx . stjude yyy . org zzz in environment production in 0.04 seconds Error: Working directory /mnt/auto/home/ miller2grp a_group /jbolling does not exist!

Error: /Stage[main]/Main/Exec[/bin/echo]/returns: change from 'notrun' to ['0'] failed: Working directory /mnt/auto/home/miller2grp/jbolling does not exist! Notice: Applied catalog in 0.12 seconds

{quote} ----

Errors of the same form are also reported by the agent under these circumstances if the catalog being applied contains `Exec` resources without {{cwd}} parameters. On the other hand, these particular failures do not occur if the {{Exec}} in question has a {{cwd}} parameter designating an existing, accessible directory, notwithstanding that the Puppet process's own working directory is inaccessible to it. Oddly enough, a different failure occurs if Puppet's working directory actually doesn't exist. That situation can be reproduced like so:

---- *Example 2*

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 any Puppet command at all, for example

{code:shell}puppet agent --test{code} or {code:shell}puppet apply --execute "exec { '/bin/echo': cwd => '/tmp' }"{code} . *_Output_* {quote}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

{quote} ----

As described in conjunction with Example 1, however, Puppet does not actually need to access the current working directory to compile or apply a catalog, at least not as a general rule, so this failure is spurious. Of course, these issues can be worked around by ensuring that the working directory is an existing, accessible one before running Puppet, and I imagine that both failure scenarios presented are unlikely for most people. However, I personally hit the Example 1 case often enough to inspire me to file this report. I note also that it's distinctly more annoying when it occurs as a result of {{puppet agent --test}} ing a catalog that takes a minute to retrieve and a few minutes to apply, and there is some risk that such a failure leaves the system in an unexpected state requiring manual intervention.

Add Comment

[John Bollinger (JIRA)]

John Bollinger updated an issue

Puppet / PUP-10080 Exec resources fail if the working directory is inaccessible Change By: John Bollinger

*Puppet Version:* 6.8.1 *Puppet Server Version:* 6.5.0 *OS Name/Version:* CentOS 7 Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist. I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I {{sudo}} a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple {{Exec}} resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the {{Exec}} should fail. *Desired Behavior:* {{Exec}} resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the {{cwd}} parameter. Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason. *Actual Behavior:*

{{Exec}} resources with no {{cwd}} spuriously specified fail spuriously when Puppet's working directory cannot be accessed, even when execution of the command does not depend on accessing that directory. The specific failure mode seems to depend on details of the situation, but the one I normally run into can be reproduced with {{puppet apply}}, too, like so:

---- *Example 1* 1. log in to a machine on which my home directory is on an automounted NFS file system with root squashing in effect 2. {{sudo bash}} to obtain a root shell 3. Execute {code:shell}puppet apply --execute "exec { '/bin/echo': }"{code} *_Output:_*

{quote}Notice: Compiled catalog for xxx.yyy.zzz in environment production in 0.04 seconds Error: Working directory /mnt/auto/home/a_group/jbolling does not exist!

[John Bollinger (JIRA)]

John Bollinger updated an issue

Puppet / PUP-10080 Exec resources fail if the working directory is inaccessible Change By: John Bollinger

*Puppet Version:* 6.8.1 *Puppet Server Version:* 6.5.0 *OS Name/Version:* CentOS 7 Exec resources fail unnecessarily when the working directory from which the 'agent' or 'apply' face is launched does not exist or is inaccessible to puppet. Additionally, in the event that the working directory exists but is inaccessible to the process, the diagnostic emitted incorrectly reports that the directory does not exist. I typically observe this on machines where my home directory is NFS-mounted, such that it is inaccessible to the local root account. With that as my working directory, I {{sudo}} a privileged shell in which to run the Puppet agent, but catalog application fails on account of errors from multiple {{Exec}} resources. Changing directory to a root-accessible one allows catalog application to succeed. In at least some cases, the command being executed is insensitive to the accessibility of the working directory, so there's no particular reason that the {{Exec}} should fail. *Desired Behavior:* {{Exec}} resources should not automatically fail on account of a missing or inaccessible working directory, unless a specific working directory is requested via the {{cwd}} parameter. Puppet, generally, should not rely on the working directory being accessible except where it actually needs to access it for some configuration-, face-, or catalog-specific reason. *Actual Behavior:*

{{Exec}} resources with no {{cwd}} spuriously fail when the Puppet's working directory cannot be accessed, even when no particular working directory is specified, and even when execution of the command does not depend on accessing the working that directory. The specific failure mode seems to depend on details of the situation, but the one I normally run into can be reproduced with {{puppet apply}}, too, like so:

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible Thanks John Bollinger. Could you run the first example with --trace? It may be related to PUP-9997 The second case is failing due to facter. Could you file a FACT ticket for that? [root@rbbd3d3x1dbupp3 test]# facter --debug

shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

2019-10-03 17:16:34.811353 INFO puppetlabs.facter - executed with command line: --debug. 2019-10-03 17:16:34.812893 INFO leatherman.ruby:139 - ruby loaded from "/opt/puppetlabs/puppet/lib/libruby.so.2.5.3". 2019-10-03 17:16:34.813368 DEBUG leatherman.dynamic_library:77 - symbol rb_data_object_alloc not found in library /opt/puppetlabs/puppet/lib/libruby.so.2.5.3, trying alias rb_data_object_wrap. 2019-10-03 17:16:34.893465 INFO leatherman.ruby:195 - using ruby version 2.5.3 2019-10-03 17:16:34.893562 INFO puppetlabs.facter - resolving all facts. 2019-10-03 17:16:34.893661 DEBUG puppetlabs.facter - fact "facterversion" has resolved to "3.14.3". 2019-10-03 17:16:34.893774 DEBUG puppetlabs.facter - fact "aio_agent_version" has resolved to "6.8.1". 2019-10-03 17:16:34.894163 DEBUG leatherman.file_util:65 - Error reading file: No such file or directory 2019-10-03 17:16:34.895305 FATAL puppetlabs.facter - unhandled exception: boost::filesystem::current_path: No such file or directory

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

FACT-2055 created for the Facter side.

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

Trace of example 1: # puppet apply --trace --execute "exec { '/bin/echo': }" Notice: Compiled catalog for moby.stjude.org in environment production in 0.04 seconds Error: Working directory /mnt/auto/home/miller2grp/jbolling does not exist! /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/execution.rb:196:in `execute' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec.rb:60:in `block in run' /opt/puppetlabs/puppet/lib/ruby/2.5.0/timeout.rb:93:in `block in timeout' /opt/puppetlabs/puppet/lib/ruby/2.5.0/timeout.rb:103:in `timeout' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec.rb:53:in `run' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/provider/exec/posix.rb:45:in `run' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/exec.rb:133:in `block in sync' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/exec.rb:130:in `times' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/type/exec.rb:130:in `sync' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:241:in `sync' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:136:in `sync_if_needed' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:90:in `block in perform_changes' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:89:in `each' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:89:in `perform_changes' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:21:in `evaluate' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:263:in `apply' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:283:in `eval_resource' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:187:in `call' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:187:in `block (2 levels) in evaluate' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:521:in `block in thinmark' /opt/puppetlabs/puppet/lib/ruby/2.5.0/benchmark.rb:308:in `realtime' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:520:in `thinmark' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:187:in `block in evaluate' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/graph/relationship_graph.rb:122:in `traverse' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction.rb:174:in `evaluate' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:240:in `block (2 levels) in apply' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:521:in `block in thinmark' /opt/puppetlabs/puppet/lib/ruby/2.5.0/benchmark.rb:308:in `realtime' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:520:in `thinmark' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:239:in `block in apply' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:161:in `with_destination' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/transaction/report.rb:146:in `as_logging_destination' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:238:in `apply' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:194:in `block (2 levels) in apply_catalog' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:521:in `block in thinmark' /opt/puppetlabs/puppet/lib/ruby/2.5.0/benchmark.rb:308:in `realtime' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:520:in `thinmark' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:193:in `block in apply_catalog' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:233:in `block in benchmark' /opt/puppetlabs/puppet/lib/ruby/2.5.0/benchmark.rb:308:in `realtime' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:232:in `benchmark' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:192:in `apply_catalog' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:381:in `run_internal' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:242:in `block in run' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/context.rb:65:in `override' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:266:in `override' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:219:in `run' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/apply.rb:343:in `apply_catalog' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/apply.rb:260:in `block (2 levels) in main' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/context.rb:65:in `override' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:266:in `override' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/apply.rb:243:in `block in main' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/context.rb:65:in `override' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:266:in `override' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/apply.rb:207:in `main' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/apply.rb:177:in `run_command' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:382:in `block in run' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:687:in `exit_on_fail' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:382:in `run' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:143:in `run' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:77:in `execute' /opt/puppetlabs/puppet/bin/puppet:5:in `<main>'

Error: /Stage[main]/Main/Exec[/bin/echo]/returns: change from 'notrun' to ['0'] failed: Working directory /mnt/auto/home/miller2grp/jbolling does not exist!

Notice: Applied catalog in 0.14 seconds

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper updated an issue

Puppet / PUP-10080

Exec resources fail if the working directory is inaccessible

Change By: Josh Cooper Team: Coremunity

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible The base exec provider is defaulting the cwd, which seems wrong if it's not being managed. If I comment out that line, then I run into the facter issue.

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

Huh.  Do you reproduce example 1 with unmodified Puppet, Josh Cooper?  Because when I hit the facter issue, it seems like puppet doesn't go anywhere at all – even puppet help fails – yet under Example 1 circumstances (the working directory exists but is inaccessible) an Exec with cwd set applies successfully for me. That would be Example 3  Set up as in Example 1 Execute the command

puppet apply --execute "exec { '/bin/echo': cwd => '/tmp' }"

The catalog is compiled and applied successfully in that case.

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

I don't have an easy way to reproduce example 1

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

I agree that this issue is related to PUP-9997, but I think the key observation is Josh's from a few comments back: that it is inappropriate for the Exec provider to default the cwd parameter.  Instead, if no value is specified for that parameter then the provider ought not to attempt to change directory at all, neither in the parent nor in the child. Such a change should be pretty safe from unwanted side effects, for in the vast majority of cases, changing the working directory to the same directory it already is, as Puppet does now, will have the same observable effects as the proposed behavior of not changing it at all.

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

I confirm that modifying the base Exec provider to avoid defaulting the cwd parameter resolves the Example 1 case for me.  All unit tests continue to pass with that change.  I would be prepared to submit a PR, but I'm not sure how to write tests that demonstrate the issue in the unpatched code, and I'm uncertain whether this ought to instead be rolled in as part of a larger patch addressing PUP-9997. Advice?

Add Comment

[James Ralston (JIRA)]

James Ralston commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

John Bollinger, I'll defer to Puppet folks who want to chime in, but as the reporter of PUP-9997, I would just submit a PR with the code fixes and no tests. From looking at the code for the Exec provider, I think the only thing that is required is removing the cwd ||= Dir.pwd line, as Puppet::Util::Execution.execute() only calls Dir.chdir if the cwd parameter was set. Did you come to a different conclusion?

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

James Ralston, I came to the same conclusion about the code change to be made, +/- explanatory code comments.  That seems to be what Josh Cooper was looking at, too.  I guess I can go ahead and submit the PR, and Puppet can kick it back to me if they don't want it.

Add Comment

[James Ralston (JIRA)]

James Ralston commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

John Bollinger, I propose that there are two separate issues here: Puppet misbehaves / fails if the cwd is inaccessible. Puppet misbehaves / fails if the cwd does not exist. I reopend my ticket PUP-9997, which is solely about issue #1. Would you be willing to confine issue #1 to PUP-9997, and keep issue #2 confined to this ticket?

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper updated an issue

Puppet / PUP-10080

Exec resources fail if the working directory is inaccessible

Change By: Josh Cooper Fix Version/s: PUP 6.4.5 Fix Version/s: PUP 5.5.18 Fix Version/s: PUP 6.11.0

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper assigned an issue to Josh Cooper

Puppet / PUP-10080 Exec resources fail if the working directory is inaccessible

Change By: Josh Cooper Assignee: Josh Cooper

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper updated an issue

Puppet / PUP-10080 Exec resources fail if the working directory is inaccessible

Change By: Josh Cooper Sprint: Platform Core KANBAN

Add Comment

[Josh Cooper (JIRA)]

Josh Cooper commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible I agree. Let's close this as a dup of PUP-9997, update PR https://github.com/puppetlabs/puppet/pull/7775 to reference PUP-5915, and track the general issue of Dir.chdir in PUP-9997.

Add Comment

[John Bollinger (JIRA)]

John Bollinger commented on PUP-10080

Re: Exec resources fail if the working directory is inaccessible

For the record, I'm fine with this resolution.  I agree that my example 1 is among the cases covered by PUP-9997, but not necessarily the only such case.  My example #2 has already been reassigned to FACT-2055.

Add Comment