-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Minion sending duplicate events #62959
Comments
The events are nine seconds apart, which seems like a lot. |
I've ran another test, here's the trace: Click
|
It appears the the event is re-sent after a timeout.
This may be related to #62881. |
It seems so yes. I do want to note that I've ran these tests on fresh machines with 0 load. |
Is the minion configured with multiple masters? |
Could you please try with 3006.0? I've created a test case mimicking your steps and I even repeat the process 3 times before giving up and so far I haven't received the same even twice in my test runs. |
Just tested this on 2 fresh Ubuntu 22 VM's with salt 3006, one being master, the other having only the minion installed. Trace from both master and minion is attached below. I've ran the tests described here: #62638. We're not using multiple masters. Minion
Master
|
Thanks for the additional information. This has been set to be fixed in 3006.2. Any chance you can create a Vagrant file or Dockerfile that will help me replicate this issue when I dive in? If not no worries, I'll see if I can't replicate it using a new Ubuntu 22 VM. |
I do see this issue regularly with the updated Vault integration (#62684) and expiry events turned on (https://github.com/lkubb/salt/blob/32f977335765c530c66417a78504fdfde3dbdabd/salt/modules/vault.py#L413-L420):
In this case, the events are received exactly at 7 seconds apart, matching There will likely be a much easier way to reproduce this behavior, but for the record, this happens every time I run This is on v3006.1 (all daemons). Edit: I have a reactor for this event putting some strain on the master, but removing it still exhibits the same behavior. |
Hi,
Those already running v3006.1 (FreeBSD 13, Alpine 318) and the OpenBSD ones (7.2, 7.3) stuck on 3003.5 did not cause such errors. When I update a Debian 11/12 or Ubuntu 22.04 to Salt 3006.1 using the "latest" repos instead of the 3005 one the messages for those minions I've updated stop. Oh, right, in case it somehow matters: The master is running 3006.1 on Debian 11. |
Not sure if it related or not, but I have 2 or 3 cases of |
I am able to replicate this on the head of 3006.x with the original submitter test case, but it looks to be fixed on the head of master. Can anyone confirm this as well? |
I'm going to go ahead and close this, but let me know if I need to re-open if anyone confirms that its not fixed on master. |
So it's not going to be fixed in 3006, despite that being an LTS release and this being a regression? |
I have not been able to successfully bisect the issue to determine which code to cherry pick. I can try a few more times and try to look at the git log around that code to see if we can't narrow it down as well. |
I still have not been able to narrow down the fix, so this will be included in 3007.0. |
…sc#1213257) This reverts commits: saltstack/salt@a99ffb5 saltstack/salt@80ae518 saltstack/salt@3c7e1ec saltstack/salt@171926c From this PR: saltstack/salt#61468 See: saltstack/salt#62959 (comment)
…sc#1213257) * Revert usage of long running REQ channel (bsc#1213960, bsc#1213630, bsc#1213257) This reverts commits: saltstack/salt@a99ffb5 saltstack/salt@80ae518 saltstack/salt@3c7e1ec saltstack/salt@171926c From this PR: saltstack/salt#61468 See: saltstack/salt#62959 (comment) * Revert "Fix linter" This reverts commit d09d2d3. * Revert "add a regression test" This reverts commit b2c32be. * Fix failing tests after reverting commits
Description
When running
event.send
in a state executed from the master to a minion, the minion sends duplicate events to the bus. This happens most of the times, but not always.It does not happen when:
event.send
from the master usingsalt myminion event.send test123
event.send
from the minion usingsalt-call event.send test123
salt-call state.apply test123
from the minionIt looks like the behaviour reported in #53506 but the other way around. It also causes the behaviour reported in #62638
Setup
/srv/salt/test123.sls
:salt myminion state.apply test123
salt-run state.event test123
Expected behavior
I expect events to always be sent once.
Versions Report
Additional context
I've tested this on Ubuntu20 (both classic and onedir install methods) and ubuntu22.
I did not see this behaviour in previous salt versions (3004.x).
The text was updated successfully, but these errors were encountered: