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

Service systemd implementation should not fallback to use sysvinit one #319

Open
guillemj opened this issue Feb 23, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@guillemj
Copy link
Contributor

commented Feb 23, 2018

The current service_systemd.go implementation is falling back to use the sysvinit one (service_init.go) when the commands give an error exit core. This is wrong, because systemd should have either generated a service file for those sysvinit init scripts, or it or the admin might have disabled or masked those services, so falling back will give the wrong result. But it will definitely not pay attention to those sysvinit services outside of its compat support anyway, so either systemctl knows about it, or for all practical purposes it does not matter at all.

The case in point here for us, was the motd service, which is masked on Debian, so systemctl is-enabled motd will return an error code, but while having the Debian initscripts package installed, there will be sysvinit enabled service present, so a check expecting the service to be disabled and not running will fail with an unexpected result when it should have succeeded.

guillemj added a commit to guillemj/goss that referenced this issue Apr 11, 2018

Fix systemd service implementation to not fallback to sysv (aelsabbah…
…y#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 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.

guillemj added a commit to guillemj/goss that referenced this issue Aug 14, 2018

Fix systemd service implementation to not fallback to sysv (aelsabbah…
…y#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.
@taurus-forever

This comment has been minimized.

Copy link

commented May 22, 2019

@aelsabbahy Is it possible to pay attention to the current pull request?
At the moment we have stuck on 0.3.5+patch from pull request,
but we would like to upgrade 0.3.7+ one day.

Our problem is simple: goss doesn't behave well on systemd based servers
where some services are disabled but they are also provide sysvinit scripts.
Race condition happens when we disable/mask such service in
systemd using the standard systemd approaches. In this case goss calls sysvinit scripts.

We need a way to disable fallback to sysvinit if service is masked/disabled in systemd.
The proposed pull request just removes fallback as logically is it wrong, IMHO.
Maybe you are worrying for backward compatibility here, in this case maybe
we can have agree on some goss configuration option which will keep current defaults
but allows us to disable fallback? Tnx!

aelsabbahy added a commit that referenced this issue May 22, 2019

Fix systemd service implementation to not fallback to sysv (#319) (#374)
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

This comment has been minimized.

Copy link
Owner

commented May 22, 2019

Sorry for missing this in the last release. I merged the PR into master. Can you confirm that master looks good.

Once we sort out #446 I can cut a new release.

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.