1

This bash script worked fine alone:

#!/bin/bash
OtherIP=172.17.1.2
while [ true ]
do
  echo "cannot connect to $OtherIP" >>pgha.log
  sleep 2s
  psql -h $OtherIP -U checker -c '\l' template1 &>/dev/null

  if [ $? -eq 0 ]; then
        echo `date` 'Finally,' >>pgha.log
        echo 'pgpool is available on host='$OtherIP  >>pgha.log
        break
  fi
done

Basically, as I start postgresql on the server 172.17.1.2 this script would jump out of the loop and write the last words "pgpool is available on host=172.17.1.2". But as I put this script in systemd service it no longer output to pgha.log, here is auto_pgha.service:

[Unit]
Description=run pgpool after auto_pgha service ## <-change run_XXX.sh

[Service]
Type=oneshot
ExecStart=/root/test1.sh ## <-change run_XXX.sh

[Install]
WantedBy=multi-user.target

Fair enough, I have also checked systemctl status auto_pgha after enabling it and reboot the server while 172.17.1.2 server did not run postgresql, it says activating

● auto_pgha.service - run pgpool after auto_pgha service ## <-change run_XXX.sh
     Loaded: loaded (/usr/lib/systemd/system/auto_pgha.service; enabled; vendor preset: disabled)
     Active: activating (start) since Fri 2023-06-30 15:30:51 CST; 35s ago
   Main PID: 563 (test1.sh)
      Tasks: 2 (limit: 4656)
     Memory: 1.9M
        CPU: 74ms
     CGroup: /system.slice/auto_pgha.service
             ├─ 563 /bin/bash /root/test1.sh ## "<-change" run_XXX.sh
             └─3833 sleep 2s

After starting postgresql on 172.17.1.2, it is dead as expected but still nothing in pgha.log - in fact, no file pgha.log at all since I deleted it before reboot. How can I fix this error?

George Y
  • 528
  • 6
  • 16

1 Answers1

0

IMO your code looks good, except for a detail.

It won't work:

echo "cannot connect to $OtherIP" >>pgha.log

It is expected to work:

echo "cannot connect to $OtherIP" >> pgha.log
Arrow Root
  • 102
  • 11
  • 1
    Thanks for reply. But I found `pgha.log` in `/`, `WorkingDirectory=/root` would fix this issue. – George Y Jul 03 '23 at 09:52
  • 1
    This is not right in general; pretty much _all_ shells parse and accept `>file` in the same way as `> file` (and likewise for all other redirect operators). – user1686 Jul 07 '23 at 08:04