I’ve been noticing that at least one of my cookbooks is causing the
associated service to be restarted everytime chef runs. None of the
config files that trigger “notifies” are being changed and the Chef
logs confirm that. The only thing that seems to be triggering the
restart is:
service “programname” do
action [:enable, :start]
supports :restart => true
end
In the logs:
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action enable (programname::default line 86)
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action start (programname::default line 86)
The service is restarting properly, but interrupting active sessions
every 15 minutes is not acceptable. How can I keep Chef from
restarting the process unless something has changed?
-J
Use supports :status to check the init script for status, or specify a
pattern for the default "ps and grep" behavior
On Jun 13, 2011 5:19 PM, "Jason J. W. Williams" jasonjwwilliams@gmail.com
wrote:
I've been noticing that at least one of my cookbooks is causing the
associated service to be restarted everytime chef runs. None of the
config files that trigger "notifies" are being changed and the Chef
logs confirm that. The only thing that seems to be triggering the
restart is:
service "programname" do
action [:enable, :start]
supports :restart => true
end
In the logs:
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action enable (programname::default line 86)
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action start (programname::default line 86)
The service is restarting properly, but interrupting active sessions
every 15 minutes is not acceptable. How can I keep Chef from
restarting the process unless something has changed?
-J
That helped. Turns out also that my git :sync on the repo is
triggering the restart:
git "/git/programname" do
repository ""
reference node[:programname][:version]
ssh_wrapper "/usr/bin/deploy-ssh-wrapper.sh"
action :sync
notifies :restart, "service[programname]"
end
Is there anyway to keep it from triggering a notifies event if the
repo hasn't changed?
-J
On Mon, Jun 13, 2011 at 6:21 PM, AJ Christensen aj@junglist.gen.nz wrote:
Use supports :status to check the init script for status, or specify a
pattern for the default "ps and grep" behavior
On Jun 13, 2011 5:19 PM, "Jason J. W. Williams" jasonjwwilliams@gmail.com
wrote:
I've been noticing that at least one of my cookbooks is causing the
associated service to be restarted everytime chef runs. None of the
config files that trigger "notifies" are being changed and the Chef
logs confirm that. The only thing that seems to be triggering the
restart is:
service "programname" do
action [:enable, :start]
supports :restart => true
end
In the logs:
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action enable (programname::default line 86)
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action start (programname::default line 86)
The service is restarting properly, but interrupting active sessions
every 15 minutes is not acceptable. How can I keep Chef from
restarting the process unless something has changed?
-J
Doesn't sync just track a remote reference?
Surely it would be obvious with debug logging. 
On Jun 13, 2011 5:48 PM, "Jason J. W. Williams" jasonjwwilliams@gmail.com
wrote:
That helped. Turns out also that my git :sync on the repo is
triggering the restart:
git "/git/programname" do
repository ""
reference node[:programname][:version]
ssh_wrapper "/usr/bin/deploy-ssh-wrapper.sh"
action :sync
notifies :restart, "service[programname]"
end
Is there anyway to keep it from triggering a notifies event if the
repo hasn't changed?
-J
On Mon, Jun 13, 2011 at 6:21 PM, AJ Christensen aj@junglist.gen.nz
wrote:
Use supports :status to check the init script for status, or specify a
pattern for the default "ps and grep" behavior
On Jun 13, 2011 5:19 PM, "Jason J. W. Williams" <
jasonjwwilliams@gmail.com>
wrote:
I've been noticing that at least one of my cookbooks is causing the
associated service to be restarted everytime chef runs. None of the
config files that trigger "notifies" are being changed and the Chef
logs confirm that. The only thing that seems to be triggering the
restart is:
service "programname" do
action [:enable, :start]
supports :restart => true
end
In the logs:
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action enable (programname::default line 86)
[Tue, 14 Jun 2011 00:14:27 +0000] INFO: Processing
service[programname] action start (programname::default line 86)
The service is restarting properly, but interrupting active sessions
every 15 minutes is not acceptable. How can I keep Chef from
restarting the process unless something has changed?
-J
On Mon, Jun 13, 2011 at 6:50 PM, AJ Christensen aj@junglist.gen.nz wrote:
Doesn't sync just track a remote reference?
Surely it would be obvious with debug logging.
The culprit seems to be this line:
[Tue, 14 Jun 2011 00:43:32 +0000] DEBUG: git[/git/progname] current
revision: ce24a6cc63aa39b2f5cc81539d7497a4a27fc563 target revision:
6174a2af6cd7bae0d516337de08edffad023850a
The revision is set to a tag (not a branch) called "3.0.3a".
Technically, since it's a Git annotated tag, it get's it's own object
hash: 6174a2af6cd7bae0d516337de08edffad023850a. However, the actual
commit revision's hash is ce24a6cc63aa39b2f5cc81539d7497a4a27fc563. So
when Chef checks it out the repo shows
ce24a6cc63aa39b2f5cc81539d7497a4a27fc563 as the commit. Then on the
next Chef run, Chef doesn't understand that it shouldn't be comparing
the tag's ID to the most recent repo commit ID, because they'll always
be different. Only way around it seems to be to use lightweight tags,
but then you lose annotation messages etc on the tag.
-J
Sounds like the perfect amount of diagnostics for a well identified bug.
Feel free to log a ticket specifying the correct behavior
On Jun 13, 2011 6:06 PM, "Jason J. W. Williams" jasonjwwilliams@gmail.com
wrote:
On Mon, Jun 13, 2011 at 6:50 PM, AJ Christensen aj@junglist.gen.nz
wrote:
Doesn't sync just track a remote reference?
Surely it would be obvious with debug logging.
The culprit seems to be this line:
[Tue, 14 Jun 2011 00:43:32 +0000] DEBUG: git[/git/progname] current
revision: ce24a6cc63aa39b2f5cc81539d7497a4a27fc563 target revision:
6174a2af6cd7bae0d516337de08edffad023850a
The revision is set to a tag (not a branch) called "3.0.3a".
Technically, since it's a Git annotated tag, it get's it's own object
hash: 6174a2af6cd7bae0d516337de08edffad023850a. However, the actual
commit revision's hash is ce24a6cc63aa39b2f5cc81539d7497a4a27fc563. So
when Chef checks it out the repo shows
ce24a6cc63aa39b2f5cc81539d7497a4a27fc563 as the commit. Then on the
next Chef run, Chef doesn't understand that it shouldn't be comparing
the tag's ID to the most recent repo commit ID, because they'll always
be different. Only way around it seems to be to use lightweight tags,
but then you lose annotation messages etc on the tag.
-J
On Mon, Jun 13, 2011 at 7:08 PM, AJ Christensen aj@junglist.gen.nz wrote:
Sounds like the perfect amount of diagnostics for a well identified bug.
Feel free to log a ticket specifying the correct behavior
Which I take to mean...there isn't some flag or directive I'm missing
in the cookbook...dang. Alright...open a bug ticket I will. Thanks for
the help.
-J
http://tickets.opscode.com/browse/CHEF-2420
On Mon, Jun 13, 2011 at 7:11 PM, Jason J. W. Williams
jasonjwwilliams@gmail.com wrote:
On Mon, Jun 13, 2011 at 7:08 PM, AJ Christensen aj@junglist.gen.nz wrote:
Sounds like the perfect amount of diagnostics for a well identified bug.
Feel free to log a ticket specifying the correct behavior
Which I take to mean...there isn't some flag or directive I'm missing
in the cookbook...dang. Alright...open a bug ticket I will. Thanks for
the help.
-J