extended_bin: Avoid using logger

[weiss]

The user running the release may not have the privileges required to using logger(1). In that case, logger(1) returns non-zero, so the extended start script would fail (due to set -e).

Modern systems (e.g., systemd-based or container solutions) typically expect services to write log messages to the standard output, and the extended start script does this in other places already. Therefore, just don't bother with logger(1) anymore.

[weiss]

If you'd rather stick to using logger(1) if possible, I'd suggest to just fall back to echo in case logger(1) exists non-zero (git pull https://github.com/weiss/relx.git fix/catch-logger-failure).

[tsloughter]

Hm, yes, this is probably for the best.

[tsloughter]

I do worry if anyone is expecting that log message in their system logs. I kinda doubt it but have no way to guarantee that, which is my only hangup.

[tsloughter]

I wonder if if ! command -v logger > /dev/null 2>&1 was meat to catch issues calling logger but doesn't work?

This is code that has been carried over for nearly decades now from riak I believe.

[weiss]

I do worry if anyone is expecting that log message in their system logs. I kinda doubt it but have no way to guarantee that, which is my only hangup.

Yes I was wondering myself. So #948 is probably the safer solution, and this PR could be closed.

I wonder if if ! command -v logger > /dev/null 2>&1 was meat to catch issues calling logger but doesn't work?

That part makes sure the logger command exists before trying to use it. My user ran into the case where the command does exist but executing it without special privileges failed (/dev/log isn't world-writable on a AlmaLinux 8, see processone/eturnal#84 (comment)).

[ferd]

Agreed the other version looks like a better plan.