Custom init.d script not starting

Chef Infra (archive)
1

Hello everyone,

I’m building a cookbook that installs InspIRCd from source. It doesn’t
install an init.d script, so I made my own in templates. However, I’m
finding that the call to the service resource doesn’t start the IRC server,
even though the chef-client output seems to indicate it does. I am,
however, able to start it via “sudo /etc/init.d/inspircd start” or “sudo
service inspircd start”. Here’s some code snippets:

inspircd.initd.erb

#!/bin/bash

init.d script for inspircd

su - irc -c “<%= “#{node[‘inspircd’][‘install_dir’]}” %>/inspircd $*”

default.rb

template “/etc/init.d/inspircd” do
source "inspircd.initd.erb"
owner "root"
group "root"
mode "0744"
end

service “inspircd” do
supports :status => true, :restart => true
action [ :enable, :start ]
end

chef-client output

…
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing
template[/etc/init.d/inspircd] action create (inspircd::default line 72)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd] action
enable (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd] action
start (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Chef Run complete in 0.6536 seconds
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Running report handlers
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Report handlers complete

Any help would be appreciated. Thank you.

All the best,

Arthur Kalmenson

2

Hi Arthur,

From the looks of your template, it appears that you're trying to write an Upstart script. I would first double-check to make sure that the Chef service provider given your operating system is looking in that directory for init scripts:

http://wiki.opscode.com/display/chef/Resources#Resources-Service

Secondly, I would check to make sure that the PID Upstart is capturing from inspircd (you can get this by checking the status of the service) is the same as the one you see in ps aux | grep inspired. Upstart will capture the PID of the parent process (that spawned the daemon) instead of the child process (the actual daemon).

--
Hector

On Friday, January 13, 2012 at 5:38 PM, Arthur Kalmenson wrote:

Hello everyone,

I'm building a cookbook that installs InspIRCd from source. It doesn't install an init.d script, so I made my own in templates. However, I'm finding that the call to the service resource doesn't start the IRC server, even though the chef-client output seems to indicate it does. I am, however, able to start it via "sudo /etc/init.d/inspircd start" or "sudo service inspircd start". Here's some code snippets:

inspircd.initd.erb

#!/bin/bash

init.d script for inspircd

su - irc -c "<%= "#{node['inspircd']['install_dir']}" %>/inspircd $*"

default.rb

template "/etc/init.d/inspircd" do
source "inspircd.initd.erb"
owner "root"
group "root"
mode "0744"
end

service "inspircd" do
supports :status => true, :restart => true
action [ :enable, :start ]
end

chef-client output

....
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing template[/etc/init.d/inspircd] action create (inspircd::default line 72)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd] action enable (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd] action start (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Chef Run complete in 0.6536 seconds
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Running report handlers
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Report handlers complete

Any help would be appreciated. Thank you.

All the best,--
Arthur Kalmenson

3

Make sure the status command actually works and returns proper exit
statuses that reflect if the service is running. For example, if the
status command is broken and always returns 0 then chef would think
the service was running already and wouldn't try to start it. This
would create the behavior you describe. Also, you can do a run in
debug (chef-client -l debug) and you'll get a little more info back
when it checks whether or not to start the service.

If you find the status command is broken, you can either fix it or
switch to using the pattern attribute to the service resource to cause
the provider to grep the process list rather than using the init
script's status command.

KC

On Fri, Jan 13, 2012 at 3:19 PM, Hector Castro hectcastro@gmail.com wrote:

Hi Arthur,

From the looks of your template, it appears that you're trying to write an
Upstart script. I would first double-check to make sure that the Chef
service provider given your operating system is looking in that directory
for init scripts:

http://wiki.opscode.com/display/chef/Resources#Resources-Service

Secondly, I would check to make sure that the PID Upstart is capturing from
inspircd (you can get this by checking the status of the service) is the
same as the one you see in ps aux | grep inspired. Upstart will capture
the PID of the parent process (that spawned the daemon) instead of the child
process (the actual daemon).

--
Hector

On Friday, January 13, 2012 at 5:38 PM, Arthur Kalmenson wrote:

Hello everyone,

I'm building a cookbook that installs InspIRCd from source. It doesn't
install an init.d script, so I made my own in templates. However, I'm
finding that the call to the service resource doesn't start the IRC server,
even though the chef-client output seems to indicate it does. I am, however,
able to start it via "sudo /etc/init.d/inspircd start" or "sudo service
inspircd start". Here's some code snippets:

inspircd.initd.erb

#!/bin/bash

init.d script for inspircd

su - irc -c "<%= "#{node['inspircd']['install_dir']}" %>/inspircd $*"

default.rb

template "/etc/init.d/inspircd" do
source "inspircd.initd.erb"
owner "root"
group "root"
mode "0744"
end

service "inspircd" do
supports :status => true, :restart => true
action [ :enable, :start ]
end

chef-client output

....
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing
template[/etc/init.d/inspircd] action create (inspircd::default line 72)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd] action
enable (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd] action
start (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Chef Run complete in 0.6536 seconds
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Running report handlers
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Report handlers complete

Any help would be appreciated. Thank you.

All the best,

Arthur Kalmenson

4

Thank you Hector and KC for your help. You were right that the status was
not returning the correct exit code (always returning 0). Since I named the
service name the same as the process, I just followed the documentation
that said:

":status - the init script or other service provider can use a status
command to determine if the service is running. If this is not specified,
Chef will attempt to match the service_name against the process table as a
regular expression, unless pattern is specified as a parameter attribute."

I removed that status was supported in default.rb, so now Chef uses the
process table correctly. My service command looks as follows now:

service "inspircd" do
supports :restart => true
action [ :enable, :start ]
end

Thanks again everyone.

Arthur Kalmenson

On Fri, Jan 13, 2012 at 6:47 PM, KC Braunschweig
kcbraunschweig@gmail.comwrote:

Make sure the status command actually works and returns proper exit
statuses that reflect if the service is running. For example, if the
status command is broken and always returns 0 then chef would think
the service was running already and wouldn't try to start it. This
would create the behavior you describe. Also, you can do a run in
debug (chef-client -l debug) and you'll get a little more info back
when it checks whether or not to start the service.

If you find the status command is broken, you can either fix it or
switch to using the pattern attribute to the service resource to cause
the provider to grep the process list rather than using the init
script's status command.

KC

On Fri, Jan 13, 2012 at 3:19 PM, Hector Castro hectcastro@gmail.com
wrote:

Hi Arthur,

From the looks of your template, it appears that you're trying to write
an
Upstart script. I would first double-check to make sure that the Chef
service provider given your operating system is looking in that directory
for init scripts:

http://wiki.opscode.com/display/chef/Resources#Resources-Service

Secondly, I would check to make sure that the PID Upstart is capturing
from
inspircd (you can get this by checking the status of the service) is
the
same as the one you see in ps aux | grep inspired. Upstart will
capture
the PID of the parent process (that spawned the daemon) instead of the
child
process (the actual daemon).

--
Hector

On Friday, January 13, 2012 at 5:38 PM, Arthur Kalmenson wrote:

Hello everyone,

I'm building a cookbook that installs InspIRCd from source. It doesn't
install an init.d script, so I made my own in templates. However, I'm
finding that the call to the service resource doesn't start the IRC
server,
even though the chef-client output seems to indicate it does. I am,
however,
able to start it via "sudo /etc/init.d/inspircd start" or "sudo service
inspircd start". Here's some code snippets:

inspircd.initd.erb

#!/bin/bash

init.d script for inspircd

su - irc -c "<%= "#{node['inspircd']['install_dir']}" %>/inspircd $*"

default.rb

template "/etc/init.d/inspircd" do
source "inspircd.initd.erb"
owner "root"
group "root"
mode "0744"
end

service "inspircd" do
supports :status => true, :restart => true
action [ :enable, :start ]
end

chef-client output

....
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing
template[/etc/init.d/inspircd] action create (inspircd::default line 72)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd]
action
enable (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Processing service[inspircd]
action
start (inspircd::default line 79)
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Chef Run complete in 0.6536
seconds
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Running report handlers
[Fri, 13 Jan 2012 17:29:02 -0500] INFO: Report handlers complete

Any help would be appreciated. Thank you.

All the best,

Arthur Kalmenson