wrong init_package on ubuntu 14.04

[axos88]

Description

init_package should report upstart, but it reports init. the contents of /proc/1/cmdline is not enough for determining the init system:

root@webfe:~# cat /proc/1/cmdline 
/sbin/initroot@webfe:~# 

I've seen reports that it does not work with later versions of the OS either, which run systemd

Ohai Version

master

Platform Version

root@webfe:/proc/1# uname -a
Linux webfe.akosv.com 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28 20:42:26 UTC 2016     x86_64 x86_64 x86_64 GNU/Linux
root@webfe:/proc/1# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS"

Ohai Output

init

[axos88]

This however gives the correct output. Maybe could be used as an additional check?

 /sbin/init --version
init (upstart 1.12.1)
Copyright (C) 2006-2014 Canonical Ltd., 2011 Scott James Remnant

This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[tas50]

I'm open to changing this. It's been a frustration of mine since the init_package attribute was launched in the first place. It would need to go into Ohai 14 since it's a breaking change, but I think it would make a lot of people quite happy.

[majormoses]

So that works when it's upstart but systemd does not support the --version. I honestly think we are going to have to rely on multiple pieces of information and try several bad things to actually determine it correctly. If only they could all get together and give us a real api of some sort to determine this.

[tas50]

the other problem is init_package should also be init_packages since there's the possibility of supporting more than 1. RHEL 6 for example does sys-v and upstart.

[majormoses]

Ya most distros actually provide more than one init system. Ubuntu has supported sys-v, upstart, and systemd since at least 14.04. Will need to use multiple pieces of information to determine "prefered" init system even if it supports multiple. So far this is what I have found:
when /proc/1/comm == systemd that is pretty definitive that it is prefered. When it is init it is upstart or sys-v this can be determined via parsing out /sbin/init --version so far from my tests. I will see if I can do some more testing across more platforms and see if I can confirm this is right. So far it does for Ubuntu (14|16).04

[majormoses]

Seeing the output from a bunch of systems should let us know if we still need more checks to properly determine.

#!/usr/bin/env ruby


proc_comm = ''
init_system = ''

if File.exists?('/proc/1/comm')
  File.open('/proc/1/comm') do |f|
    proc_comm = f.gets.chomp
  end
  if proc_comm == 'systemd'
    init_system = 'systemd'
  elsif proc_comm == 'init'
    command = `sudo /sbin/init --version`
    version_string = command.first.split("\n")
    if version_string.match(/upstart/)
      init_system = 'upstart'
    else
      init_system = 'init'
    end
  end
end

p init_system

Another option for systemd detection that is probably less reliable (and unlikely needed) would be to grep the /sbin/init binary for systemd. I believe the same will work for upstart. These checks will be super brittle in comparison though so I hope they are not needed.

[majormoses]

If anyone who has access to a very diverse set of platforms could run the script posted above and share the outputs in a gist that would be great. If we can confirm that the added checks help ensure the appropriate outcome I can work on a PR.

On the note of specialized systems like rancheros which have some form of docker as PID 1 I have no idea how we should handle that. Not sure if we should even waste cycles contemplating it as they are unlikely to be running chef on it. Thoughts? Open to suggestions.

[tas50]

So we discussed this one internally and we've decided to actually leave this one as-is. We want to avoid a lot of one off logic in this detection and instead rely on exactly what the OS returns to us. Since Ubuntu 14.04 is going EOL early next year I suspect most people have already implemented workarounds for this in their code.

[lock]

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.