Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 2 May 2014 07:30:51 -0700
From: Isaac Dunham <>
Subject: fmtmsg, syslog, and /dev/console

As far as I can tell, the fmtmsg patch is waiting for comments due to the
use of /dev/console; syslog() does not write to /dev/console, and Rich
was asking about consistency. In other words, should both functions, 
neither, or only one write to /dev/console?

I would argue that making syslog() not write to the system console is 
reasonable since the console is a peripheral fallback in case of the 
failure of the logging facility, but that fmtmsg() is intended to 
generate a message for reading immediately, which requires the ability to
write to the system console.

If stderr is redirected to a log (or if it's closed, as in a forking daemon),
one would likely not have opportunity to read messages in a timely manner 
unless a log-watcher is installed.

On the other side of things, if syslog() ends up not being able to log
messages it usually means someone doesn't care about logs.

The standard describes the two functions thus (current posix-manpages, 
corresponding to POSIX2013):

The syslog() function shall send a message to an implementation-defined logging facility, which may log it in an implementation-defined system log, write it to the system console, forward it to a list of users, or forward it to the logging facility on another host over the network.

The fmtmsg() function shall display messages in a specified format 
instead of the traditonal printf() function.
Based on a message's classification component, fmtmsg() shall write a 
formatted message either to standard error, to the console, or to both.

Isaac Dunham

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.