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

OHAI-420: Add support for determining which package is running as init #301

Merged
merged 4 commits into from Mar 21, 2014

Conversation

Projects
None yet
5 participants
@sersut
Copy link
Member

sersut commented Mar 20, 2014

Ports #108 to Ohai 7.

The only question is what happens on non-linux OSes. I believe the right thing is not to report init_package and fail as follows when queried for that attribute (might be prettier but for later version IMO):

/Users/serdar/oc/oss/ohai/lib/ohai/system.rb:180:in `attributes_print': I cannot find an attribute named init_package! (ArgumentError)
    from /Users/serdar/oc/oss/ohai/lib/ohai/application.rb:94:in `block in run_application'
    from /Users/serdar/oc/oss/ohai/lib/ohai/application.rb:93:in `each'
    from /Users/serdar/oc/oss/ohai/lib/ohai/application.rb:93:in `run_application'
    from /Users/serdar/oc/oss/ohai/lib/ohai/application.rb:70:in `run'
    from /Users/serdar/oc/oss/ohai/bin/ohai:51:in `<top (required)>'
    from /Users/serdar/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bin/ohai:23:in `load'
    from /Users/serdar/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/bin/ohai:23:in `<main>'

@danielsdeleo thoughts?

@plugin.stub(:collect_os).and_return("linux")

@mock_file = double("/proc/1/comm")
@mock_file.stub(:gets).and_return("init\n")

This comment has been minimized.

@btm

btm Mar 21, 2014

Member

Since we're not defaulting to returning "init" can you move this line down into the test for init? I presumed otherwise when I first looked at that test.

This comment has been minimized.

@sersut

sersut Mar 21, 2014

Author Member

👍

@danielsdeleo

This comment has been minimized.

Copy link
Member

danielsdeleo commented Mar 21, 2014

For new code, should we standardize on using let() and such in the tests? Looking at @btm's comment, I think that aspect of the tests may be more clearly expressed with something like:

let(:proc1_content) { "a value set for each test" }
let(:proc_1_file) { double("/proc/1/comm", :gets => proc1_content) }
@danielsdeleo

This comment has been minimized.

Copy link
Member

danielsdeleo commented Mar 21, 2014

Aside from the question on the tests, 👍

@sersut

This comment has been minimized.

Copy link
Member Author

sersut commented Mar 21, 2014

Spec is fixed per comments.

sersut pushed a commit that referenced this pull request Mar 21, 2014

Serdar Sutay
Merge pull request #301 from opscode/OHAI-420-2
OHAI-420: Add support for determining which package is running as init

@sersut sersut merged commit b5c8ec3 into master Mar 21, 2014

1 check passed

default The Travis CI build passed
Details

@sersut sersut deleted the OHAI-420-2 branch Mar 21, 2014

@sciurus

This comment has been minimized.

Copy link

sciurus commented Sep 3, 2014

Was a goal of this to allow cookbook authors to default to creating the proper configuration for the init system in use on a system? To do that, you need to be able to distinguish between at least sysvinit, upstart, and systemd. However, init_package reports both sysvinit and upstart as init.

To give you more context, I came across this while looking for a way to simplify the logstash_service LWRP, which currently has some half working and half broken/outdated logic around platorm_family and platform_version to determine which init system to configure.

@btm

This comment has been minimized.

Copy link
Member

btm commented Sep 3, 2014

@sciurus This plugin determines what the process name of PID 1 is on your system. What does ps ax | head -2 return on your system? What are the contents of /proc/1/comm ? Presumably they are "init" in both cases.

I did a little poking and it looks like Upstart replaced /sbin/init starting with Ubuntu 9.10. If you want to add on to this feature to detect when upstart is PID 1, that would be a useful feature to add. Perhaps you could search for upstart in /sbin/init, I see it occurs a lot. Similarly it would be useful to detect some other init systems, such as launchd on OS X.

@sciurus

This comment has been minimized.

Copy link

sciurus commented Sep 3, 2014

Further digging shows it's also possible for init_package to report init when the init system in use is systemd. This occurs on e.g. Debian where switching to systemd involves symlinking /sbin/init to systemd.

In this unix.stackexchange question people throw out some ideas for detecting the init system, but no suggestion stands out as the right way to do it. I like your idea of searching for the name in /sbin/init; a quick check shows it should work.

vagrant@server-debian-76:~$ strings /sbin/init | grep sysvinit | wc -l
1
[vagrant@server-fedora-20 ~]$ strings /sbin/init | grep systemd | wc -l
203
vagrant@server-ubuntu-1204:~$ strings /sbin/init | grep upstart | wc -l
3

I may take a crack at implementing this.

@danielsdeleo

This comment has been minimized.

Copy link
Member

danielsdeleo commented Sep 3, 2014

On some systems, strings is only part of some dev(el) package, maybe you can grep directly or just use ruby? General approach seems sane given the (crappy) constraints we have to deal with.

@btm btm referenced this pull request Sep 4, 2014

Closed

jjasghar/ubuntu init provider #44

@sciurus

This comment has been minimized.

Copy link

sciurus commented Sep 28, 2014

Sure, just reading the file in ruby makes sense.

I wonder if, in addition to returning the init system in use, ohai should also return the version of it. For example, before version 1.4 upstart did not support setuid or setgid. Thus, cookbook authors may want to generate different configurations depending on the upstart version.

Pleaserun has put some effort into mapping distributions to init systems and version.

@sciurus sciurus referenced this pull request Sep 28, 2014

Closed

Rework service logic #354

@chef chef locked and limited conversation to collaborators Nov 16, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.