I’ve written a lwrp with, at the end of the provider a service start:
It works as expected, I’m testing it here: https://github.com/arussel/chef-java-wrapper/blob/master/test/fixtures/cookbooks/test_java_wrapper/recipes/default.rb
when I log into the instance, as expected, I have a jetty and a play
service running. The problem is that if I use the jetty resource first like
this:
java_wrapper ‘jetty’ do
app_parameters [“org.mortbay.start.Main”]
classpath ["/usr/local/jetty/start.jar"]
java_parameters ["-Djetty.home=/usr/local/jetty"]
end
java_wrapper ‘play’ do
classpath ["#{helloworld_dir}/target/staged/*"]
app_parameters [“play.core.server.NettyServer”, “#{helloworld_dir}”]
java_parameters ["-Dhttp.port=9001"]
end
then jetty service is started, but the play is not, the last logs shows:
It works as expected, I'm testing it here: https://github.com/arussel/chef-java-wrapper/blob/master/test/fixtures/cookbooks/test_java_wrapper/recipes/default.rb
when I log into the instance, as expected, I have a jetty and a play service running. The problem is that if I use the jetty resource first like this:
java_wrapper 'jetty' do
app_parameters ["org.mortbay.start.Main"]
classpath ["/usr/local/jetty/start.jar"]
java_parameters ["-Djetty.home=/usr/local/jetty"]
end
java_wrapper 'play' do
classpath ["#{helloworld_dir}/target/staged/*"]
app_parameters ["play.core.server.NettyServer", "#{helloworld_dir}"]
java_parameters ["-Dhttp.port=9001"]
end
then jetty service is started, but the play is not, the last logs shows:
- enable service service[play]
service[play] action start[2013-11-04T11:44:41+00:00] INFO: Processing service[play] action start (/tmp/kitchen-chef-solo/cookbooks/java_wrapper/providers/default.rb line 65)
(up to date)
It stops here, when if it is started properly, there is one more line:
start service service[play]
If I log in and run 'sudo /etc/init.d/play start', the service starts without problem. I have a very hard time finding why it behaves this way.
Alex
Try running with -ldebug to see if you get any new information. Chef might think the service is running, which could indicate an issue with the init script, but that’s a semi-wild guess.
a wild but very helpful guess. The script was fine and 'service status
play' was returning the proper value, but because I hadn't use:
supports :restart => true, :status => true
in my resource declaration, chef wasn't using the 'service' to do it (I
thought that would be the default behavior), so chef was greppping the
process list. Jetty was started with a --display-name option. Chef would
see it when grepping for 'play' service and assume play was started. This
explain why play then jetty was working, but not jetty then play.
Adding the supports line to my resource has fixed everything
I think the default value for suppports here http://docs.opscode.com/resource_service.html are wrong.
Thanks,
Alex
On Mon, Nov 4, 2013 at 11:01 PM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, November 4, 2013 at 3:58 AM, Alexandre Russel wrote:
Hi all,
I've written a lwrp with, at the end of the provider a service start:
It stops here, when if it is started properly, there is one more line:
start service service[play]
If I log in and run 'sudo /etc/init.d/play start', the service starts
without problem. I have a very hard time finding why it behaves this way.
Alex
Try running with -ldebug to see if you get any new information. Chef
might think the service is running, which could indicate an issue with the
init script, but that’s a semi-wild guess.
Can you create a ticket detailing exactly what’s wrong with the docs with a code example? Our doc writer can typically turn those around very quickly.
Thank you,
--
Daniel DeLeo
On Tuesday, November 5, 2013 at 2:19 AM, Alexandre Russel wrote:
a wild but very helpful guess. The script was fine and 'service status play' was returning the proper value, but because I hadn't use:
supports :restart => true, :status => true
in my resource declaration, chef wasn't using the 'service' to do it (I thought that would be the default behavior), so chef was greppping the process list. Jetty was started with a --display-name option. Chef would see it when grepping for 'play' service and assume play was started. This explain why play then jetty was working, but not jetty then play.
Adding the supports line to my resource has fixed everything
I think the default value for suppports here http://docs.opscode.com/resource_service.html are wrong.
It works as expected, I'm testing it here: https://github.com/arussel/chef-java-wrapper/blob/master/test/fixtures/cookbooks/test_java_wrapper/recipes/default.rb
when I log into the instance, as expected, I have a jetty and a play service running. The problem is that if I use the jetty resource first like this:
java_wrapper 'jetty' do
app_parameters ["org.mortbay.start.Main"]
classpath ["/usr/local/jetty/start.jar"]
java_parameters ["-Djetty.home=/usr/local/jetty"]
end
java_wrapper 'play' do
classpath ["#{helloworld_dir}/target/staged/*"]
app_parameters ["play.core.server.NettyServer", "#{helloworld_dir}"]
java_parameters ["-Dhttp.port=9001"]
end
then jetty service is started, but the play is not, the last logs shows:
- enable service service[play]
service[play] action start[2013-11-04T11:44:41+00:00] INFO: Processing service[play] action start (/tmp/kitchen-chef-solo/cookbooks/java_wrapper/providers/default.rb line 65)
(up to date)
It stops here, when if it is started properly, there is one more line:
start service service[play]
If I log in and run 'sudo /etc/init.d/play start', the service starts without problem. I have a very hard time finding why it behaves this way.
Alex
Try running with -ldebug to see if you get any new information. Chef might think the service is running, which could indicate an issue with the init script, but that’s a semi-wild guess.