3.18 kernel detection breaks ansible service hooks #1976
Assignees
Comments
|
@wyaeld thanks for reporting this! We will take a look. |
|
@olivielpeau can you take a look please ? |
|
A temporary/hacky solution (I was tasked with a bulk-deployment today) is to modify line 20 here EC2 AMI :
Debian/Ubuntu :
Also add another block to start the agent :
|
|
Thanks for the workaround @aster1sk ! |
olivielpeau
added a commit
that referenced
this issue
Oct 20, 2015
The exit code of the `status` command has to be one of 0, 1, 2, 3, 4, 69 to be correctly understood by Ansible, but was returning `253` when the agent was not running. Normalize the exit code to 1 to avoid the issue. See https://github.com/ansible/ansible-modules-core/blob/cbbb20b6bf0d82fdc92f064c9e4d18c04f203da6/system/service.py#L590 Fixes #1976
olivielpeau
added a commit
that referenced
this issue
Oct 20, 2015
The exit code of the `status` command has to be one of 0, 1, 2, 3, 4, 69 to be correctly understood by Ansible, but was returning `253` when the agent was not running on linux kernel versions 3.18+ Normalize the exit code to 1 to avoid the issue. See https://github.com/ansible/ansible-modules-core/blob/cbbb20b6bf0d82fdc92f064c9e4d18c04f203da6/system/service.py#L590 Fixes #1976
olivielpeau
added a commit
that referenced
this issue
Oct 20, 2015
The exit code of the `status` command has to be one of 0, 1, 2, 3, 4, 69 to be correctly understood by Ansible, but was returning `253` when the agent was not running on linux kernel versions 3.18+ Normalize the exit code to 0 or 1 to avoid the issue. See https://github.com/ansible/ansible-modules-core/blob/cbbb20b6bf0d82fdc92f064c9e4d18c04f203da6/system/service.py#L590 Fixes #1976
|
Found the original cause of the issue (see #1988). Until the fix is shipped another workaround could be to use the |
urosgruber
pushed a commit
to urosgruber/dd-agent
that referenced
this issue
Dec 23, 2015
The exit code of the `status` command has to be one of 0, 1, 2, 3, 4, 69 to be correctly understood by Ansible, but was returning `253` when the agent was not running on linux kernel versions 3.18+ Normalize the exit code to 0 or 1 to avoid the issue. See https://github.com/ansible/ansible-modules-core/blob/cbbb20b6bf0d82fdc92f064c9e4d18c04f203da6/system/service.py#L590 Fixes DataDog#1976
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
a5dda4a by @JohnLZeller appears to be solving a problem related to overlayfs and the kernel.
However not everyone on 3.18 is using overlayfs. This check is creating a new problem.
The ansible-datadog role, https://github.com/DataDog/ansible-datadog uses the ansible core module for service management here https://github.com/DataDog/ansible-datadog/blob/master/tasks/main.yml#L20
This commit breaks it, since the service module expects an output it doesn't get on the
infocall.I'm using 14.04.3 LTS Ubuntu, nothing to do with CoreOS and OverlayFS
The text was updated successfully, but these errors were encountered: