Skip to content
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

Fix systemd service implementation to not fallback to sysv (#319) #374

Merged
merged 1 commit into from May 22, 2019

Conversation

Projects
None yet
2 participants
@guillemj
Copy link
Contributor

commented Aug 14, 2018

[ This is a reiteration of a previous pull request, hopefully fixing the concerns raised there. Although I found it weird that the previous pull was just closed, instead of leaving it open so that it could be reworked, for something that is a problem that should affect all non-legacy systemd based systems... I've fixed it only for Debian, because that was the reason for the introduction of the initial workaround, and I don't feel like perhaps regressing other systems using systemd , even though I think they are also currently broken. ]

The current service_systemd.go implementation is falling back to use the
sysvinit one (service_init.go) when the commands give an error exit code.

This is wrong, because systemd should have either generated a service
file for those sysvinit init scripts, or systemd itself or the admin
might have disabled or masked those services, so falling back will give
the wrong result. Because it will definitely not pay attention to those
sysvinit services outside of its compat support anyway, so either
systemctl knows about them, or for all practical purposes it does not
matter at all.

This affects at least any Debian system starting with stretch (9.x).
We check for any older system and only fallback when using a legacy
systemd.

Of course if there is no need to have transparent goss definitions that
should work on services provided by either sysvinit or systemd, then an
option is to hardcode the systemd full service name as in .socket,
.service, or similar, which means the sysvinit fallback will
always fail, and we will then preserve the failure from systemd.

Fix systemd service implementation to not fallback to sysv (#319)
The current service_systemd.go implementation is falling back to use the
sysvinit one (service_init.go) when the commands give an error exit code.

This is wrong, because systemd should have either generated a service
file for those sysvinit init scripts, or systemd itself or the admin
might have disabled or masked those services, so falling back will give
the wrong result. Because it will definitely not pay attention to those
sysvinit services outside of its compat support anyway, so either
systemctl knows about them, or for all practical purposes it does not
matter at all.

This affects at least any Debian system starting with stretch (9.x).
We check for any older system and only fallback when using a legacy
systemd.

Of course if there is no need to have transparent goss definitions that
should work on services provided by either sysvinit or systemd, then an
option is to hardcode the systemd full service name as in <unit>.socket,
<unit>.service, or similar, which means the sysvinit fallback will
always fail, and we will then preserve the failure from systemd.

@aelsabbahy aelsabbahy merged commit aa58d49 into aelsabbahy:master May 22, 2019

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.