dietpi-ddns/update.sh does not log message

[jtmoon79]

Creating a bug report/issue

Required Information

• DietPi version |

  G_DIETPI_VERSION_CORE=8
  G_DIETPI_VERSION_SUB=11
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'
  G_LIVE_PATCH_STATUS[0]='not applicable'
  

• Distro version | bullseye

Additional Information (if applicable)

• Software title | dietpi-ddns
• Was the software title installed freshly or updated/migrated? Yes.
• Can this issue be replicated on a fresh installation of DietPi? Yes.

Steps to reproduce

1. run dietpi-ddns
2. add an entry for a duckdns name
3. this creates /var/lib/dietpi/dietpi-ddns/update.sh

curl -4 -sSfL 'https://www.duckdns.org/update?domains=my-domain.duckdns.org&token=ec793bf0-f379-470d-9635-cca24e2e3f7e' 2>&1 > /dev/null | logger -t dietpi-ddns -p 3

5. tail systemctl logs
   journalctl -xf
6. manually run /var/lib/dietpi/dietpi-ddns/update.sh

Expected behaviour

Should see logger message.

Actual behaviour

There is no logger message.

Extra details

In generated script /var/lib/dietpi/dietpi-ddns/update.sh, remove redirect to /dev/null/

#!/bin/dash
curl -4 -sSfL 'https://www.duckdns.org/update?domains=my-domain.duckdns.org&token=ec793bf0-f379-470d-9635-cca24e2e3f7e' 2>&1 | logger -t dietpi-ddns -p 3

Feature Creep

While you're at it, I recommend changing the script /var/lib/dietpi/dietpi-ddns/update.sh

• adding a logger message about which domain will be updated
• passing logger the CLI option -s (print stderr), so manual calls to the script will print something

#!/bin/dash
logger -t dietpi-ddns -s -- "update domain my-domain.duckdns.org"
curl -4 -sSfL 'https://www.duckdns.org/update?domains=my-domain.duckdns.org&token=ec793bf0-f379-470d-9635-cca24e2e3f7e' 2>&1 | logger -t dietpi-ddns -p 3 -s

[MichaIng]

Thanks for reporting.

I was confused now as well, but it actually makes sense as it is: I didn't want to spam the system log with some cryptic or redundant successful HTTP response, but only when the request failed, implying error HTTP responses thanks to -f flag. Since STDERR is redirected to STDOUT first, it is passed to the logger correctly.

And since Cron cannot handle outputs, as long as no MTA is configured, I do not want anything on STDOUT or STDERR, which is the reason why stuff is send to system logger in the first place. As since this is also done when you manually call the script, having error messages duplicated to STDERR aren't such a significant benefit, is it?

The problem with adding the domain is, aside of that it again is the syslog spam I want to avoid (its trivial to check back in dietpi-ddns if you really forgot which domain you did configure), is that with some providers you do only send a token, no domain at all, e.g. FreeDNS.

[jtmoon79]

I didn't want to spam the system log with some cryptic or redundant successful HTTP response

I prefer to know when such updates have run. The per 30 minute rate wasn't too much IMO.

But it's up to you. This Issue could be closed as "WillNotFix" if you prefer.

[MichaIng]

You see the executions by cron already:

journalctl -u cron

[MichaIng]

Best to view everything DietPi-DDNS related:

journalctl --grep dietpi-ddns

Would it be sufficient to have this documented properly? I agree that it's important to have ways to see not only errors, but that it executed at all, as well. I just want to avoid redundancy to not spam the system log too much.

[jtmoon79]

Would it be sufficient to have this documented properly?

Perhaps a user hint describing that command journalctl --grep dietpi-ddns would be sufficient. The hint could be placed somewhere in the dietpi-ddns program, or at the tail-end of the stdout output.

$ dietpi-ddns
...
[ INFO ] DietPi-DDNS | Applying DietPi-DDNS Cron job...
[ INFO ] DietPi-DDNS activity can be reviewed with command:
         journalctl --grep dietpi-ddns

I agree that it's important to have ways to see not only errors, but that it executed at all, as well. I just want to avoid redundancy to not spam the system log too much.

Would a checkbox option for verbose logging be worthwhile? i.e. another line-item in dietpi-ddns main dialog that adjusts the script /var/lib/dietpi/dietpi-ddns/update.sh. When verbose is checked/selected within dietpi-ddns then the update.sh has the above-recommended logger statements. Otherwise, the update.sh script retains it's current behavior.
This is just an off-hand consideration.

Seeing that the tagged cron messages regarding dietpi-ddns are logged, this bug is low priority or WontFix.

[MichaIng]

I implemented it just now: #7309
curl errors and actual HTTP error response codes will be logged with error severity, and all other server responses separately with info severity.