[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cron and command quote

Jeff D wrote:

T o n g wrote:

On Tue, 18 Mar 2008 03:40:35 +0100, s. keeling wrote:
I.e., somehow, the 'ps | grep' was able to find something in cron, whereas 
 when executed directly under shell:
$ ps -eaf | grep -E 'cdrecord.* -[dts]ao |cdrdao *write|growisofs.*speed='
$ /bin/sh -c "ps -eaf | grep -E 'cdrecord.* -[dts]ao |cdrdao *write|growisofs.*speed='"
I.e., if the same command are executed directly under shell the 'ps | grep' finds nothing. 
 Anyone can give some explanation?

Yes.  you're stressing either the tool, or your knowledge of it.  Put
the relevant bits in a shell script and tell cron to execute that.
Then you'll have full control.  It won't be hampered by cron's (by
design) limitations.


Nope, that didn't work. Thanks for the suggestion though s. keeling.
Here is what happened after I followed the above advice.

Now the crontab reads:

 * * * * *    root    is_burning || logger get executed.

+ set -x
+ ps -eaf
+ grep -E  -[dts]ao |cdrdao *write|growisofs.*speed='
root 15306 15295 0 09:29 ? 00:00:00 grep -E cdrecord.* -[dts]ao |cdrdao *write|growisofs.*speed= 
+ exit 0

$ is_burning || echo not burning CD/DVD
not burning CD/DVD
I.e., having put the 'ps | grep' part into a shell script, the behavior is 
still the same.
Does it has anything to do with busybox?

Thanks
|| will not return true for you here, ever. you need to use && or use an if statement. Also, if you are going to be using a shell script you have to make sure that it exits properly. I would recommend putting the whole thing into a shell script:
if ps -eaf | grep -v grep | grep -E 'cdrecord.* -[dts]ao |cdrdao \ *write|growisofs.*speed=' >> /dev/null 2>&1 ; then 
    logger get executed
fi
If I followed the above discussion correctly, the OP's concern is that sometimes the grep will return a result, even when the specified cd related programs are not running, and that this happens when the grep is run from cron but not from the command line.
If this is correct, the results you're seeing can in fact happen in either case. Whether you see a result or not is totally dependent on the process scheduler, timing of execution slices and perhaps your processor speed and/or if it's an SMP environment.
What's happening is the grep you're running is sometimes finding itself. For example: 

  ps -ef|grep firefox|cut -c1-60
  rmcgowan 17073 16974  0 08:13 ?        00:00:00 /bin/sh /usr
  rmcgowan 17080 17073  0 08:13 ?        00:00:00 /bin/sh /usr
  rmcgowan 17106 17080  0 08:13 ?        00:00:59 /usr/local/f
  rmcgowan 30742 17130  0 10:49 pts/1    00:00:00 grep firefox
The last line is the grep that ran. So, one line is sometimes returned, even when firefox is not running.
There are a number of ways to get around the problem. My favorite is to use something that will show up in the ps output for the grep itself but which will not be part of what you're looking for. But this does require using either the -l or -f options (which it looks like you are). 

  ps -ef | grep '[f]irefox'
will eliminate the grep command itself because the pattern can never match itself. 

If you don't want to use the options, you could use this instead:

  ps -e | grep firefox | grep -v grep
Which will first filter for all lines with firefox, then for all lines without grep. 

I hope this helps solve your problem.

--
Bob McGowan

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply to: