Skip to content

Hacky Bug Fix to support Amazon Linux and Datadog agent 6#413

Closed
jcarr-sailthru wants to merge 1 commit intoDataDog:masterfrom
carnivalmobile:fix-amazon-linux-upstart
Closed

Hacky Bug Fix to support Amazon Linux and Datadog agent 6#413
jcarr-sailthru wants to merge 1 commit intoDataDog:masterfrom
carnivalmobile:fix-amazon-linux-upstart

Conversation

@jcarr-sailthru
Copy link
Copy Markdown
Contributor

This isn't a good fix. Submitting this not as a PR intending to be merged, but as a discussion point for how to fix this problem.

The problem is that Amazon Linux doesn't have systemd, but it does have Upstart. The Datadog RPM installs an upstart configuration, but Puppet tries to use the service command to start/stop/status the service which fails on Amazon Linux.

By setting the provider to Upstart, we can ensure that on Amazon Linux Puppet is able to start the agent using Upstart correctly.

Personally I'd consider this a bug in Amazon Linux really, but it's going to fix itself when people move to Amazon Linux 2 that was recently released which now moves to using systemd.

I believe this might also be an issue for RHEL 6 which also pre-dates systemd and ships with a weird upstart-sysvinit hybrid.

Ideal fix would be setting the provider to upstart for RHEL 6 and Amazon Linux 1, and systemd for RHEL 7 and Amazon Linux 2.... Leaving this as an exercise to the Datadog team since I only run Amazon Linux 1 right now and thus this hacky fix was more than enough to solve my problem.

This isn't a good fix. The problem is that Amazon Linux doesn't have systemd,
but it does have Upstart. The Datadog RPM installs an upstart configuration, but
Puppet tries to use the service command to start/stop/status the service which
fails on Amazon Linux.

By setting the provider to Upstart, we can ensure that on Amazon Linux Puppet
is able to start the agent using Upstart correctly.

Personally I'd consider this a bug in Amazon Linux really, but it's going to
fix itself when people move to Amazon Linux 2 that was recently released which
now moves to using systemd.
@truthbk
Copy link
Copy Markdown
Member

truthbk commented Mar 14, 2018

Thank you for this @jcarr-sailthru, we should maybe allow overriding the provider because we've encountered issues of similar nature with other distros in the past.

@jcarr-sailthru
Copy link
Copy Markdown
Contributor Author

Overriding the provider is probably the easiest solution - otherwise you'll have to maintain a mapping of troublesome OSes to providers which is bit of a pain, although does make things easier for users.

@ipleten
Copy link
Copy Markdown

ipleten commented Jul 3, 2018

So will it be fixed? Currently we are maintaining our current version of that puppet module which is annoying.

@truthbk
Copy link
Copy Markdown
Member

truthbk commented Jul 5, 2018

Sorry for the long wait, been swamped. So as mentioned, the easiest way that occurs to me without having to create a list from hell that we will forever have to maintain, and which puppet already has (and to avoid potential conflicts in the future), I'm going with the service provider override:
#444

Thank you @jcarr-sailthru and @ipleten , we'll get that PR reviewed ASAP, merged, and released in the next couple of days.

@truthbk truthbk closed this Jul 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants