Messages

The issue with the "endlessly spawning" sensor processes has been investigated by me and I invented a workaround.

It is documented at the end of my German blogpost – feel free to share it:
https://andersgood.de/blog/oeffentliche-ip-adressen-in-opnsense-mit-maltrail-absichern

The involved Monit scripts can be found here:
- https://codeberg.org/SWEETGOOD/shell-scripts/src/branch/main/OPNsense/check-maltrail-sensor-processes.sh
- https://codeberg.org/SWEETGOOD/shell-scripts/src/branch/main/OPNsense/kill-maltrail-sensors-and-restart.sh

Thanks for your improvements.

Especially the data rentention command was critical you were absolutely right.

I changed both and commited a new version. Should both be fixed now.

Thanks!

[zwingend 127.0.0.1]

Hallo zusammen,

nach meinen ausführlichen Recherchen von heute, habe ich wohl die häufigste Ursache für die Timeouts gefunden:

Bei NUT muss zwingend 127.0.0.1 als zusätzlicher Listener-Host angegeben werden (falls man ihn normal ins Netzwerk exposen möchte), sonst läuft die Diagnose ins Leere und die GUI hängt für ca. 20 Minuten.

Es ist nach dem Issue von hier (https://github.com/opnsense/plugins/issues/3304) zwar so, dass jeder Konfigurationsfehler zu einem Timeout führt, aber die aus meiner Sicht häufigste Ursache ist sicher eine geänderte Listening-Adresse.

Habe das alles auch nochmal ausführlich in meinem Blogbeitrag beschrieben:
https://andersgood.de/panel/pages/kurz-notiert+opnsense-apcupsd-und-nut-parallel-betreiben

Viel Freude beim Lesen 8)

I took your script as an example and created a version which also encrypts the backups using GPG.

You can find the script here:
https://codeberg.org/SWEETGOOD/andersgood-opnsense-scripts/src/branch/main/backup-opnsense-via-api.sh

I also wrote a short blogpost in German with some explanations:
https://andersgood.de/kurz-notiert/opnsense-per-api-verschluesseltes-backup-der-konfiguration-anlegen

Thanks to the TS for your work!

I took your script as an example and created a version which also encrypts the backups using GPG.

You can find the script here:
https://codeberg.org/SWEETGOOD/andersgood-opnsense-scripts/src/branch/main/backup-opnsense-via-api.sh

I also wrote a short blogpost in German with some explanations:
https://andersgood.de/kurz-notiert/opnsense-per-api-verschluesseltes-backup-der-konfiguration-anlegen

Thanks to the TS for your work!

My assumption still is that the error is caused by either wrong (invisible) characters in the bash file or by a wrong encoding.

If you can execute other files (with the same shebang at the top) just fine there MUST be an issue with this particular file.

Not very likely if you can't even execute the script using the command line. This has nothing to do with Monit at all.

[if]

The space between the #! and the /bin/sh doesn't matter.

This line is important because it tells the interpreter how to handle the following lines. So it must stay at the top of every executable bash file.

Nevertheless I would recommend you to add the script from the thread starter block by block to my test file and execute it after every step. This might bring you to the line which causes the script to fail.

Please note that you need to add the if and the for blocks completely. So it's OK to just copy the line

maxCapacity=$1 # in percentages

for testing but the if blocks like

if [ ! "${maxCapacity}" ]; then
  printf "Missing arguments\n"
  printf "${usage}"
  exit 1
fi


and also the for block needs to be added as a whole.

And indeed you can skip all comments.

Does it also contain

#!/bin/sh

in the first line of the file? That's important that the file contains both lines as I stated in my previous post.

It could not issue the most important command so the "file preparation" was not successful:

echo '#!/bin/sh' > test.sh
/bin/sh: Event not found.

Could you please edit the file with a tool like vi or nano (the first one is available on OPNsense) and make sure its content is:

#!/bin/sh
echo SH EXECUTION TEST

Try to execute it again afterwards. Also you didn't even execute it because you missed the . at the beginning. That's why it tells you "Command not found".

No the script doesn't involve any plugin. The error message is clear and normally only shows up if either:

- the file and folder cannot be found (like the message says)
- a binary file has been compiled for a different architecture (my experience and not applicable here)

So this issue is very strange.

Let's try it step by step:

cd /root
echo '#!/bin/sh' > test.sh
echo 'echo SH EXECUTION TEST' >> test.sh
chmod +x test.sh
./test.sh

Does it show "SH EXECUTION TEST" at the end?

If you are connected via SSH you could try to run the script from there:

/root/zfs_monit.sh 80

Does that work?

Please also check if the encoding of the script is correct. You can do that with this command:

cat /root/zfs_monit.sh

The script output should look exactly like in the first post of the thread starter.

Can you login via SSH to your OPNsense, issue the following command and post the result?

ls -lart /root/zfs_monit.sh

Thanks @redbull666 for the script!

Can confirm that the script works like a charm.

Error   monit   'zfs_monit' failed to execute '/usr/local/bin/ZFS_monit.sh 80' -- No such file or directory

Are you sure the file name is named ZFS_monit.sh (instead of zfs_monit.sh)? Maybe you just move it to /root and try if it works there?