0

The script is a bit sensitive, so I'll hide some details, but the script runs up to the > mark

    auth="$(mariadb -N -h $DBHOST -P $DBPORT $DBNAME -e "SELECT ..... -u $DBUSER -p$DBPASS)"
    > ssh -i /root/.ssh/ssh_host_ed25519_key -oStrictHostKeyChecking=accept-new "IP" "do $auth"

export GFS="IPS"
for ip2 in $GFS; do ufw allow from $ip2; done
for ip2 in $GFS; do ssh -i /root/.ssh/ssh_host_ed25519_key -oStrictHostKeyChecking=accept-new -n "$ip2" "ufw allow from $MYIP"; done



...

The ssh command executes without error, then script just stops. Even with bash -x I can't see anything wrong.

It's even weirder because this only happens in the full script, if I create a test script with just the needed variables, and the same code, it runs fine.

How to debug this?

Freedo
  • 1,255
  • What shell is running your script? Are "IP" and "IPS" hidden details? – Gerard H. Pille Jan 09 '22 at 09:52
  • GFS hasn't been set readonly earlier in the script? – Gerard H. Pille Jan 09 '22 at 09:56
  • No GFS hasn't been set read-only, the IPS and IPS are my hidden ips separated by space – Freedo Jan 09 '22 at 10:27
  • Does the second line actually start with >, redirecting the -i command into a file called ssh? – Kusalananda Jan 09 '22 at 10:31
  • As written, your code hardly makes any sense. – Stéphane Chazelas Jan 09 '22 at 10:34
  • how to debug: try with set -e disabled and check the exit status of the ssh, e.g. echo "ssh exited with status $?" on the next line. Or if you need to keep set -e on, change it to ssh ... | true (with the pipe), and check ${PIPESTATUS[0]} instead of $? on the next line (in Bash only, though). I'm not sure if there's something missing, but it looks like you're passing "do $auth" as the command for ssh to run on the remote, and that's likely to give a syntax error on the remote, if there's a regular shell there. Where your errors go, well, that I can't know. – ilkkachu Jan 09 '22 at 10:42
  • anyway, if it stops on the ssh line, then the for loops after it are rather irrelevant for the issue, no? Creating a script with only the relevant parts is the right approach, but if the problem doesn't appear with such a reduced script, ...well, then it didn't contain all the relevant parts and you need to try something else. Start by removing everything after the part where it stops to reduce distractions. Then look at what the failing command relies on, and remove everything else. If it stops failing, you removed something that was important to issue. – ilkkachu Jan 09 '22 at 10:46
  • 3
    trial by error can help: remove some part that looks like it shouldn't matter, if the behaviour changed, it did matter, and you need to put it back and look closer. Repeat. The issue here wrt. the SE question is that we here have absolutely no idea what your script does, so we can't know if something you left out is important. And it's not fun to try to guess possible reasons just to find out there was actually something really simple we didn't get to see (and you didn't notice). – ilkkachu Jan 09 '22 at 10:50
  • 1
    Does it work if you use ssh -n? – terdon Jan 09 '22 at 11:04
  • I found it does work If I add -n to ssh. Should I delete the question? – Freedo Jan 19 '22 at 08:25
  • No, it's better that you add an answer to your own question with the solution, preferably after you've read about it and understood how it fixed your problem, and mark your own answer as "accepted", so people that encounter the same issue in the future could find a clear explanation here. Thanks! – aviro Jan 19 '22 at 08:42

0 Answers0