No init.d script included in icehouse ubuntu packaging

[Tim]

The upstream packages for keystone in Ubuntu 14.04 seem to be missing the init.d upstart scripts, so the post install script fails, but the package install is marked as successful. This seems like a rather large omission.

apt-get install keystone
invoke-rc.d: unknown initscript, /etc/init.d/keystone not found.
invoke-rc.d: policy-rc.d denied execution of stop.
invoke-rc.d: unknown initscript, /etc/init.d/keystone not found.
invoke-rc.d: policy-rc.d denied execution of start.

apt-cache policy keystone
keystone:
  Installed: 1:2014.1-0ubuntu1
  Candidate: 1:2014.1-0ubuntu1
  Version table:
 *** 1:2014.1-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matt Thompson (mattt416)]

This is confusing as some services like rabbitmq-server still have an init script:

root@stackforge-ubuntu:~# dpkg -S /etc/init.d/rabbitmq-server
rabbitmq-server: /etc/init.d/rabbitmq-server
root@stackforge-ubuntu:~# ls -al /etc/init.d/rabbitmq-server
-rwxr-xr-x 1 root root 3991 Mar 5 21:32 /etc/init.d/rabbitmq-server
root@stackforge-ubuntu:~# apt-cache policy rabbitmq-server
rabbitmq-server:
  Installed: 3.2.4-1
  Candidate: 3.2.4-1
  Version table:
 *** 3.2.4-1 0
        500 http://mirror.rackspace.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status
root@stackforge-ubuntu:~#

[Tim (tsm)]

Was this removal intentional? I just assumed it was an omission since it's setup process still exists in the package, and it's assumed to be that way in the docs.

[James Page (james-page)]

It is - keystone only ships an upstart configuration (no init script) which installs to /etc/init

Using the service command is the correct way to call init scripts/upstart configuration:

   sudo service keystone restart

This will ensure that the preferred method of managing the service is used - in the case of keystone, the upstart configuration on Ubuntu

[James Page (james-page)]

The errors in the original bug report are non-fatal. Packages are supposed to provide both init scripts and equivalent upstart configurations but this is not enforced.

[Tim (tsm)]

James. I thought this might be the case, but if it is, it still doesn't solve the original problem. My understanding is that Upstart scripts require registration with initctl in order for the "service" commands to work. This does not appear to be occurring during install, so the above mentioned commands don't work.

Appears to be the same for all OpenStack services.

[Todd Crane (toddjcrane)]

This bug also affects OpenStack deployment and configuration via Chef. OpenStack's official cookbooks require the initscripts or they fail.

[Spencer (rsmitty1025)]

Can confirm Todd Crane's comment. Just hit this using the StackForge coookbooks.

[Spencer (rsmitty1025)]

I was able to work around this by issuing an 'ln -s /lib/init/upstart-job /etc/init.d/keystone'

[Weidong Shao (weidongshao)]

Shall we temporary fix the cookbook by manually specifying Upstart Provider? e.g.

provider Chef::Provider::Service::Upstart if platform?("ubuntu") && node["platform_version"].to_f >= 13.10

[Todd Crane (toddjcrane)]

Maybe I'm missing something but why doesn't Canonical fix this. On one hand they advertise as being "Open-Stack Friendly" and even "the best flavor to use with OpenStack" but yet they refuse to play nice with a script that was written by OpenStack to automate installation, opting instead for "it's them who should change, not us" rhetoric. To top it all off, I fail to see the reason why support was cut in the first place.

[James Page (james-page)]

Todd

The service command should work just fine with upstart only configurations; the service command is written to use the upstart configuration on upstart based systems and sysvinit scripts on older style systems such as Debian.

[James Page (james-page)]

"To top it all off, I fail to see the reason why support was cut in the first place."

The change was made in the way init and upstart configurations are installed to align Debian and Ubuntu, so that users can choose which init system to use; same applied for systemd configurations now.

[James Page (james-page)]

Todd

Do the Chef configurations call /etc/init.d/keystone directly? or use the service command?