NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Feed facility/priority to logger(1) via stdin - desirable extension or bad idea?



Hello all,

following a short discussion on IRC, I would like to ask a question or make a suggestion.

With a lot of scripts and tools written, I have gotten into the habit of logging all logging output to stderr, as well as any form of payload to stdout. To change the logging destination depending on the operating environment, I just have to connect stderr to the desired logging tool at the end of the pipeline. In my scripts and tools, on the other hand, I don't have to worry about the logging target at all, but can work as neutrally as possible. This is similarly recommended in the environment of 12F apps[1].

In my productive NetBSD environments, this logging tool is then usually logger(1), which is at the end of the pipeline and sends the output to syslogd.

logger(1) takes a parameter -p, which I can use to set the facility and the priority. This is where it starts to get a bit uncomfortable. I have no ability to influence the facility / priority on the other side of the pipeline. This means that I lose the capabilities of Syslogd, e.g. to use different log files depending on the priority.

It would be nice if one could, for example, optionally omit the -p parameter and instead specify the facility and priority via the standard input of logger in coded form (coded with angle brackets as in the raw syslog protocol) *)

In /usr.bin/logger/logger.c there is a TODO in the else path of command line processing (chosen when no command line parameters are provided) which mirrors pretty much that idea:

```
} else	/* TODO: allow syslog-protocol messages from file/stdin
		 *       but that will require parsing the line to split
		 *       it into three fields.
		 */
		while (fgets(buf, sizeof(buf), stdin) != NULL)
			syslogp(pri, msgid, sd, "%s", buf);
```

In other implementations of logger (under [2], for example, the Linux variant), there is a --prio-prefix parameter that explicitly enables this type of handling.

My question on this:

- With reference to the TODO - would that be a welcome addition? If yes, what should be paid particular attention to?

- Can what I have in mind already be solved (differently or more elegantly) with existing tools from the base system?


Kind regards
Matthias


*) You could then decide in your scripts, depending on whether stderr is connected to a terminal or a pipe, whether you want to output nice coloured terminal logging or logging optimised for syslog with a prefix


[1] https://12factor.net/logs
[2] https://man7.org/linux/man-pages/man1/logger.1.html


Home | Main Index | Thread Index | Old Index