-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
generate unit file for st2api, st2auth and st2stream #721
base: master
Are you sure you want to change the base?
Conversation
… variables are used consistently for .socket and .service files.
…s in post installation.
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.
Looks like a bit of copy pasta. I left suggestions to fix the ports.
Also, I wonder if we could combine these so one generator handles all 3 services. But it's probably not worth the effort.
User=st2 | ||
Group=st2 | ||
Environment="DAEMON_ARGS=-k eventlet -b 127.0.0.1:9101 --workers 1 --threads 1 --graceful-timeout 10 --timeout 30 --log-config /etc/st2/logging.api.gunicorn.conf --error-logfile /var/log/st2/st2api.log" | ||
EnvironmentFile=-/etc/default/st2api |
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.
I just noticed that the generator does not include EnvironmentFile
any more.
One good thing, is that makes the generator truly agnostic between debian vs EL.
One potential gotcha is that if anyone is relying on this, then that file will no longer be sourced. They can, however, add EnvironmentFile
to a systemd service override file /etc/systemd/system/st2api.conf.d/some-file-name-here.conf
. That can also be used to override anything else if desired. (The same applies to st2auth and st2stream)
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.
As far as I know, the /etc/default/st2api
configuration file is how Debian based distributions allowed overriding sysv and upstart service scripts. As you've rightly pointed out, people should use the built-in systemd override mechanism and all currently supported OS' are systemd based. We can highlight this in the v3.8 upgrade notes.
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.
I'm pretty sure tests are failing because this line is having an error that has been silenced:
st2-packages/packages/st2/rpm/st2.spec
Line 89 in 75a0e5e
%service_post st2actionrunner st2api st2stream st2auth st2notifier st2workflowengine |
That line lists the 6 services that aren't getting enabled correctly.
# Enable services created by systemd generator | ||
systemctl enable st2api st2auth st2stream >/dev/null 2>&1 || true | ||
systemctl start st2api st2auth st2stream >/dev/null 2>&1 || 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.
Looking at the test error for EL distros:
I think this is already handled by the %post
macro which uses the %service_post
helper. That runs:
st2-packages/rpmspec/helpers.spec
Line 86 in 23f100c
systemctl --no-reload enable %{?*} >/dev/null 2>&1 || : \ |
What if you remove the output redirection in the %service_post
macro helper? Then maybe we'll see if there's an error. And maybe remove it here too.
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.
There appears to be a worker timeout for gunicorn on EL7, but I don't think that's the cause of the services failing to start for the RPM based distros. I still don't see any errors in the logs that indicate why the service is not enabled and started.
4defc1b
to
f1e9345
Compare
f1e9345
to
11c3c76
Compare
aargh. There's still no helpful output during
st2-packages/rake/build/setup.rake Line 13 in 739d24e
We need to figure out why the |
I'm going to debug this on a VM, pushing and waiting for the CI to fail is a hindrance and unreasonably slow. |
Move api, auth and stream service unit files to generator so st2.conf variables are used consistently for .socket and .service files.