I am trying to use ps-watcher to monitor my system and make sure a given number of worker threads are working on a task. If I hard code the number of workers into the config file for ps-watcher, it works great. However I would like the number of workers to be pulled from an environment variable named WORKERS. This seems simple, but has proven to be a pain.

Here's an example config file that works:

  trigger = $count<5
  action = /home/ubuntu/startWorkers.sh

I pulled the following from the man for ps-watcher:

This parameter specifies the condition on which a process action is fired. The condition is evaluated with Perl eval() and should therefore return something which is equivalent to ``true'' in a Perl expression.

Which makes me think I should use $ENV{VARIABLE} as I would in Perl. So I tried the following:

  trigger = $count<$ENV{WORKERS}
  action = /home/ubuntu/startWorkers.sh

to which my ps-watcher log recorded the following:

Use of uninitialized value in concatenation (.) or string at (eval 6) line 1 (#1) (W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a "" or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables. To help you figure out what was undefined, perl will try to tell you the name of the variable (if any) that was undefined. In some cases it cannot do this, so it also tells you what operation you used the undefined value in. Note, however, that perl optimizes your program and the operation displayed in the warning may not necessarily appear literally in your program. For example, "that $foo" is usually optimized into "that " . $foo, and the warning will refer to the concatenation (.) operator, even though there is no . in your program.

I'm at a bit of a loss. Any help would be appreciated.


I agree with the single quote idea, but also double-check that the variable is actually exported by doing a print "$ENV{'WORKERS'}\n"; before the eval. Perhaps you are not exporting the variable into the children.

  • Also do a print of $trigger or whatever you are evaluating to double-check the resulting perl code is what you want. – Seth Robertson May 20 '11 at 19:19
  • the pain I'm having is that this is a configuration file, not a proper Perl script... although it is being parsed by Perl. I wish I could throw debugging code in there and test it, but I can't. As I think about it, I suspect you are right about this being an export problem. But I'm not sure how to verify. I may have to start digging through the source for ps-watcher. – JD Long May 20 '11 at 19:21
  • @JD Long: Then run printenv > /tmp/x in an evaluated context, or ps axewww while the program is running, to check for the environmental variable. – Seth Robertson May 20 '11 at 19:39
  • hey thanks. I slipped a printenv in there in ticks and it evaluated. And I can see that the environment variable is not being exported. Now to figure out why. – JD Long May 20 '11 at 19:51
  • @JD Long: Please upvote and accept, then. – Seth Robertson May 20 '11 at 19:53

Maybe single quotes around the environment variable?

  • I was expecting it to be something with escaping or quoting. Unfortunately the single quotes didn't change anything. – JD Long May 20 '11 at 19:18
  • Thanks for the help! The single quotes were needed, but I also had issues with the environment variable not being exported. – JD Long May 20 '11 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.