-
Notifications
You must be signed in to change notification settings - Fork 898
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
Move the systemd env var check into the systemd_worker? method #20321
Conversation
config/settings.yml
Outdated
@@ -1090,7 +1090,7 @@ | |||
:poll_method: :normal | |||
:starting_timeout: 10.minutes | |||
:stopping_timeout: 10.minutes | |||
:systemd_enabled: true | |||
:systemd_enabled: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we apparently haven't been testing with systemd enabled on appliances for jansa (probably since #19556) I think disabling this for jansa is safest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For context, we were just looking at an appliance where workers were spawned from evmserverd.service but when we inspected workers, they indicated they were systemd workers and could be the reason that we never were stopping the workers, because they were started from spawn (old way) and we were trying to stop them from systemd (which is not how they started) so nothing happened and it continually tried to stop them in the same way...
irb(main):002:0> MiqWorker.find(13504).systemd_worker?
=> true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, if this just hasn't been tested then we probably shouldn't release Jansa with it in. |
I agree that |
Agree that master should, I can create a jansa specific PR to disable it and leave the config as is on master @bdunne |
When starting a worker we were checking an env var and settings, when stopping a worker we were just checking settings. This meant that if the env var wasn't set we would start the worker with spawn and try to stop it with systemd which will fail because the unit doesn't exist.
b99e4f8
to
e1bbb20
Compare
Checked commit agrare@e1bbb20 with ruby 2.5.7, rubocop 0.69.0, haml-lint 0.28.0, and yamllint |
I agree, we can move back to systemd on master after this is backported to jansa although we'll keep the consistent checks for environment/settings 😆 |
Ugh that sucks...if we haven't been using systemd at all, then I agree that it's not safe for jansa. |
Move the systemd env var check into the systemd_worker? method (cherry picked from commit 3a7421c)
Jansa backport PR #20329 |
Backported to jansa via #20329 |
When starting a worker we were checking an env var and settings, when stopping a worker we were just checking settings. This meant that if the env var wasn't set we would start the worker with spawn and try to stop it with systemd which will fail because the unit doesn't exist.