Remove the entry from the instance map so
that a closed entry may not be reused.
This forces this operation even if the reference
count of the entry has not yet gone to zero.
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
It has been observed that when running this command:
```
salt "*" test.ping
```
sometimes the command would return `Minion did not return. [No response]`
for some of the minions even though the minions did indeed respond
(reproduced running Windows salt-master on Python 3 using the TCP
transport).
After investigating this further, it seems that there is a race condition
where if the response via event happens before events are being listened
for, the response is lost. For instance, in
`salt.client.LocalClient.cmd_cli` which is what is invoked in the command
above, it won't start listening for events until `get_cli_event_returns`
which invokes `get_iter_returns` which invokes `get_returns_no_block`
which invokes `self.event.get_event` which will connect to the event bus
if it hasn't connected yet (which is the case the first time it hits
this code). But events may be fired anytime after `self.pub()` is
executed which occurs before this code.
We need to ensure that events are being listened for before it is
possible they return. We also want to avoid issue #31454 which is what
PR #36024 fixed but in turn caused this issue. This is the approach I
have taken to try to tackle this issue:
It doesn't seem possible to generically discern if events can be
returned by a given function that invokes `run_job` and contains an
event searching function such as `get_cli_event_returns`. So for all
such functions that could possibly need to search the event bus, we
do the following:
- Record if the event bus is currently being listened to.
- When invoking `run_job`, ensure that `listen=True` so that `self.pub()`
will ensure that the event bus is listed to before sending the payload.
- When all possible event bus activities are concluded, if the event
bus was not originally being listened to, stop listening to it. This is
designed so that issue #31454 does not reappear. We do this via a
try/finally block in all instances of such code.
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
When systemd-python is not installed, systemd notification falls back to
using the systemd-notify for service notification. This cannot be used
however unless the unit has NotifyAccess=all set.
The particular use case for this is when Salt is installed using pip. We
don't put systemd-python into the requirements.txt because we can't be
sure that the minion supports systemd, so pip installs won't necessarily
have systemd-python available.
When ``file.managed`` is invoked within an archive.extracted state to
pull down the source archive, ``file.extract_hash`` is invoked with
the unique name we created for it, rather than the actual source
filename. This causes hash extraction to fail, or only return a partial
match. Either of these cases causes the ``archive.extracted`` state to
fail.
This commit adds a new optional kwarg to ``file.get_managed`` which can
be used to override which filename we pass to ``file.extract_hash``, and
then passes this kwarg to the ``file.managed`` we invoke from within the
``archive.extracted`` state.
