-
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
same error message as on issue #18504 #22571
Comments
I have 2 scheduled jobs for this minion (which is also the master) push_sudoers:
function: state.sls
minutes: 60
splay: 15
args:
- Config_TST.default.scb.sudo.sudoers
make_sudoers:
function: state.sls
seconds: 3600
splay: 900
args:
- Config_TST.default.scb.sudo.make_sudoers |
|
@BoomerB, thanks for reporting. |
Hi, |
There was a bug I introduced in early versions of 2014.7 if you were using splay without seconds, it's fixed in later versions. Possible for you to upgrade? |
error still exists in 2014.7.4 |
@ekle Thanks. Will take a look. |
@ekle Can you provide an example schedule job where you're seeing the issue? I'm attempting to duplicate the error using a really simply job with test.ping and unable to replicate the issue. Thanks! |
nothing special, just this in the pillar:
after removing the splay line, it works fine. |
Thanks. Going to fire up a Docker instance with Debian jessie and test with the packages. |
@ekle If you run the minion in debug mode, before the exception line, do you see a line that begins with 'schedule.handle_func: Adding splay of'? |
yes:
i can also reproduce this with test.ping, looks like the function does not matter |
Perfect. Now we know where the exception is happening and can hopefully figure out why. It seems to be happening because the _seconds key doesn't exist in the data dictionary, but it should be there. Let me investigate a bit more. Thanks! |
@ekle Do you have the configuration item loop_interval set in the minion configuration? |
Nevermind. Had a theory but disapproved it. |
@ekle One other question, do you see the exception on the first run? Or is it only on subsequent runs of the jobs? |
loop_interval is set to 25 |
@garethgreenaway it looks like the jobs runs a few times correct and that started to fail.
i'm not quite sure, but i think it started to fail after a saltutil.sync_all or saltutil.refresh_pillar run. |
Can you try disabling loop_interval? And ill do some tests with refresh_pillar. |
disabling loop_interval does not help |
Finally able to duplicate it. After running the saltutil.sync_all I'm seeing the issue. |
Actually refresh_pillar seems to be the culprit. Thanks for mentioning that! It looks like the job was remaining in the job queue but all the data was being refreshed by the refresh_pillar call, so my assumptions about what was in there were incorrect. Think I've got it figured out, few more tests and I'll push up a PR with the fix. Thanks again! |
@ekle Can you confirm if the pull requests linked above fixed this issue for you or not? |
installed 2015.2.0rc2-226-gb3c50c2 looks good |
Great! I am going to close this then. If it pops up again, leave a comment and we can open this again and address any additional issues. Thanks! |
The text was updated successfully, but these errors were encountered: