crontab bash tests

[lejeczek]

On 25/09/2023 01:56, Karl Auer wrote:
> On Sun, 2023-09-24 at 18:44 +0200, lejeczek via ubuntu-users wrote:
>> I have this
>>
>> */1 * * * * { [[ $(/usr/bin/sudo -u postgres /usr/bin/psql
>> [...etc...]
> Not a direct answer to your question, but I would suggest putting this
> in a script, with comments so future you knows what it's supposed to be
> doing and why, then running the script from cron. Run it from root's
> crontab and make sure it is readable, writable and executable only by
> root.
>
> Three things leap out as possible problems - no space after the closing
> parenthesis, the sudo, and ownership of the temp file. sudo will only
> work reliably if this is in root's crontab, otherwise it will ask for a
> password, and if the commands are not running as root, touch and rm may
> fail. The outermost braces don't look necessary to me, but I may be
> wrong there.
>
> In general, you don't have to wrap a command or pipeline up in "$()" if
> you just want to know if it succeeded:
>
>     if pipeline ; then { do_something ; } fi
>
> Or in your case
>
>     psql && touch || rm
>
> I would expect there to be output from your command if it were failing
> - maybe in /var/log/syslog? Or emailed to you, so check your (and
> root's) mail spools.
>
> Good luck, let us know when you've figured it out :-)
>
> Regards, K.
>
>
Failed to mention - it's root's cron.
command works, both in cron & "regular" shell
_crontab_ as such seems to work -- it;s only first bit, 
psql, which is sudoed -- but it always seems to end up with 
_false_
Having it "simplified" - in postgres' cron, so no! sudo:

*/1 * * * * [ $(psql --quiet --port=5433 -x -c 'select state 
from pg_stat_replication;' | grep streaming > /dev/null)$? 
-eq 0 ] && touch /tmp/pgSQL-5433.isMaster || rm -f 
/tmp/pgSQL-5433.isMaster

still! on the systems/boxes which outside of cron, end up 
doing _rm_, in cron does the opposite, _touch_

Something to do with _cron_ invokes bash in Ubuntu?
I've been doing this for many long years in RHEL/Centos, and 
it always worked - actually the same crontab works in 
Centos... as expected.