Use smarter default for post_install_action about chef_client_updater HOT 3 CLOSED

@tas50 @lamont-granquist thoughts on this issue?

from chef_client_updater.

the problem is that even when we do not run with interval mode we still tend to create the supervisor process and fork off a child process to do the work.

for example, when running chef-client from the command line you actually get two process. this is all likely overly complicated and poor, but the locking conditions, particularly in buggy chef 11-era versions, will still crop up if you try to exec with the supervisor process running. i'm fairly sure that chef-client --no-fork avoids the creation of the supervisor.

so you could check that chef-client is both not running in interval mode and is running no_fork and then switch to exec. and you have to check both because we used to support non-forking interval runs before 12, you can't only check no_fork.

but then the use case becomes a lot more limited since mostly nothing invokes chef-client with --no-fork afaik, and this won't fix anyone's test-kitchen runs.

i think we're long past time to fix that behavior at which point this does get more useful:

chef/chef#6712

but this here would need to check no_fork && !interval correctly.

from chef_client_updater.

(or i guess interval runs don't matter and its only no_fork that matters?)

from chef_client_updater.