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

Use systemd on RHEL/CentOS 7 #335

Merged
merged 3 commits into from
Mar 26, 2016
Merged

Conversation

joerocklin
Copy link
Contributor

On a minimal CentOS 7 system using just systemd (without initscripts installed) the service setup fails because /sbin/service isn't installed. The systemd service definitions on CentOS 7 correctly use the graceful command for the reload process.

@svanzoest
Copy link
Contributor

This looks good to me, can you update the serverspec and chefspec to match?
Do we need the provider Systemd line? if chef already does this correctly, we would not need to call it out explicitly.

@drpebcak
Copy link
Contributor

This will break Amazon Linux support #302

Amazon Linux does not use systemd, but it does return rhel for platform_family

@svanzoest
Copy link
Contributor

@drpebcak yes leaving that to chef is better rather than hard coding it.

@joerocklin
Copy link
Contributor Author

Does RHEL/etc < 7 or Amazon need the reload command defined this way external to the package-provided init scripts? Should all of the case statements just be removed?

@drpebcak
Copy link
Contributor

drpebcak commented Apr 1, 2015

I believe the Chef::Provider::Service::Init::Redhat class still looks for /sbin/service... not 100% sure though.

@svanzoest
Copy link
Contributor

@joerocklin this is because redhat (and fedora) do not use graceful, but rather use restart. See #160 among others. It seems like they fixed it in RHEL7, which means we can guard it and only use it on lower versions.

We can not decide upon a server provider and just leave that decision to chef itself. It is much better at that and it is important for that to be consistent across cookbooks.

@svanzoest
Copy link
Contributor

where are with this one @drpebcak ?

@drpebcak
Copy link
Contributor

drpebcak commented May 6, 2015

Not sure what we wanted to do for this. We could say:

if node['platform_version'].to_f < 7.0 || node['platform'] == 'amazon' 
  reload_command '/sbin/service httpd graceful'
else
  provider Chef::Provider::Service::Systemd
end

@svanzoest
Copy link
Contributor

@drpebcak I wouldn't even specify the provider, just let chef handle that.

if node['platform_version'].to_f < 7.0 || node['platform'] == 'amazon' 
  reload_command '/sbin/service httpd graceful'
end

@drpebcak
Copy link
Contributor

drpebcak commented May 8, 2015

@svanzoest would that work? I thought chef only recognizes one provider per platform (chef/chef#1717). I think we would still have to override it if we wanted to use systemd.

@drpebcak
Copy link
Contributor

drpebcak commented May 8, 2015

I'm not sure if this was implemented yet either, but this could also potentially fix this problem.

@svanzoest
Copy link
Contributor

@drpebcak It was added in chef 12 and chef-client 3.8.2 (via chef-boneyard/chef-client#190)

@drpebcak
Copy link
Contributor

drpebcak commented May 9, 2015

Do you think we could let newer chef releases pick the provider automatically, but hard code it in some places for backwards compatibility?

I think that'd be the best way to go.

@svanzoest
Copy link
Contributor

I guess we can but I do not know what we would hardcode and what it would buy us. This really not a cookbook issue as each cookbook would have the same issue.

@svanzoest svanzoest merged commit 400957d into sous-chefs:master Mar 26, 2016
svanzoest added a commit that referenced this pull request Mar 26, 2016
@lock
Copy link

lock bot commented Jul 24, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jul 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants