10

I am using debian squeeze with PostgreSQL 9.1 from backports. Puppet has version 2.7.14. Unfortunatly the init script returns the wrong exit code for status. Therefore I wrote a custom status command to detect whether postgresql is running or not.

service { 'postgresql':
  ensure => running,
  enable => true,
  hasstatus  => false,
  hasrestart => true,
  status => "pg_lsclusters -h | awk 'BEGIN {rc=0} {if ($4 != \"online\") rc=3} END { exit rc }'",
  provider => debian,
}

My command works like a charme, but puppet seems to have a problem. I always get notice: /Stage[main]/Postgresql/Service[postgresql]/ensure: ensure changed 'stopped' to 'running' although it is already running.

So tried the following:

service { 'postgresql':
  ensure => running,
  enable => true,
  hasstatus  => false,
  hasrestart => true,
  status => "exit 0",
  provider => debian,
}

As I understood this custom status command, puppet should always think that postgresql is running. Nevertheless puppet tries to start postgresql - every time.

What is my fault? Or is it a bug in puppet?

MMore
  • 523
  • 2
  • 6
  • 12
  • Your manifest looks correct, so this sounds like a bug in Puppet. It's a long shot, but try setting `provider => init` (and remove the `enable` parameter). – mgorven May 15 '12 at 18:16
  • 2
    Are you sure exit 0 is a valid command? The exit command is usually internal to a shell. Do you need to do something like bash -c 'exit 0'? – Zoredache May 15 '12 at 18:17
  • @Zoredache you are right. With sh -c 'exit 0' the `status` command of puppet works as expected! – MMore May 16 '12 at 06:36

1 Answers1

6

My best guesses are that the $4 in your command is getting swallowed up by puppet's own interpolation and that exit 0 doesn't quite work right due to shell interaction issues.

I would try a few things.

  1. If the problem is puppet's interpolation on $4 in your command escape the $ like so: status => "pg_lsclusters -h | awk 'BEGIN {rc=0} {if (\$4 != \"online\") rc=3} END { exit rc }'" (sometimes more backslashes are required, but I'm pretty sure 1 is enough here).
  2. Make sure the test command is really working right. exit is a shell internal and I'm not sure how puppet will treat that. So use the canonical "return success" command instead: status => "/bin/true"

  3. Maybe status is being overridden by provider => debian (which would be a puppet bug), so instead specify all the commands and use the base provider (this won't enable properly, however):

    service { 'postgresql':
  provider => base,
  ensure   => 'running',
  start    => '/etc/init.d/postgresql start',
  restart  => '/etc/init.d/postgresql restart',
  stop     => '/etc/init.d/postgresql stop',
  status   => "pg_lsclusters -h | awk 'BEGIN {rc=0} {if (\$4 != \"online\") rc=3} END { exit rc }'",
}
freiheit
  • 14,334
  • 1
  • 46
  • 69
  • One other thing: similar to the `exec` type, I think puppet needs full paths to executables. Try setting those to the full path in your `status` line, if you haven't set one globally? – Shane Madden May 15 '12 at 22:05
  • @ShaneMadden: Puppet doesn't necessarily need full paths to commands, though assuming it needs them doesn't hurt anything. In addition to a some sort of default path (PATH in environment daemon was started in?) `exec` accepts a `path` param and you can set a default path with `Exec { path => '/usr/bin:/bin' }` or `Exec { path => ['/usr/bin'],['/bin']}`. There's a similar 'path' on Service, but it appears to be primarily used with certain providers for finding init scripts, rather than as a normal shell-style command search path. – freiheit May 15 '12 at 22:19
  • 1
    Thanks! The interpolation of `$4` was the problem. I replaced it with `\$4` and now everything works as expected :) – MMore May 16 '12 at 06:37