Log to standard error rather than standard output

[stepnem]

Due to stdio buffering, logging to the latter isn't very useful (unless stdout is a tty, which for a daemon is a marginal use case; and even then it's customary to log to stderr).

(A concrete data point: running with '-F' under systemd, the first batch of log messages got to the journal after 4 days.)

When at it, direct also the startup error messages to stderr.

(Leave -h and -v alone, printing to stdout seems to be widespread there, although it's a mixed bag (double-checked with a few BSD and GNU utilities).)

[twekkel]

While I understand the issue, I don't see any delay when running in foreground ('-F'). Your PR will print everything to stderr, also debugging info for example... making redirect and pipe less convenient. How about the change in this branch https://github.com/twekkel/htpdate/tree/LoggingSTDERR ?

[stepnem]

While I understand the issue, I don't see any delay when running in foreground ('-F').

I suppose that would depend on whether the way you run htpdate makes stdout point to an "interactive device" or not (or otherwise influences buffering).

The solution will print everything to stderr, also debugging into for example... making redirect and pipe less convenient. How about the solution in this branch https://github.com/twekkel/htpdate/tree/LoggingSTDERR ?

While I still believe logging everything to stderr is TRT and standard practice[1], your solution should indeed make the particular -F problem go away and it's your call, of course.

(I think I'd also prefer some kind of error message instead or in addition to the abort() (there'd be two of those now); in case a cosmic ray strikes, providing a hint of what happened rather than having to root around in a core dump (maybe not even there or with no debug symbols or tooling).)

Thank you!

[1] If you wanted to distinguish different levels in the non-syslog case, you could add log level prefixes to the messages (only in that case).

Also, different behavior of stderr vs stdout can bite you even when both go to a terminal, due to possibly printing messages going to different streams out of order, and if you redirect stdout to a file or pipe you'll get full buffering again, i.e. the problem I observed, so I don't see how that's useful for monitoring a long-running program, either.

(BTW you could have also just fflush(stdout)ed after each message; if you did that I wouldn't have noticed this split logging issue to begin with.)

[twekkel]

• When running htpdate interactively or periodically from cron, logging to stdout is still preferred IMHO.
• Agreed on the abort(), added a message to deal with cosmic rays :)
• Replaced the existing abort() with an exit() to be more consistent with other error conditions... getopt() already shows an error message.