There are a few options I can think of, their effectiveness depends on how things get on to "the console".
For kernel-sourced messages the simplest is to use
dmesg -n 1 to disable (practically all) console messages, and use syslogd/klogd to extract and either log them or forward them. All kernel messages still get logged and are accessible via
sys_syslog()) regardless of the console log level. A variation on this is to boot your kernel with
quiet which suppresses
printk() output, and rely only on syslogd/klogd to process kernel messages.
A more adventurous and comprehensive option is to use a console module, these are more commonly used in VM guests so that the VM host can access guest consoles directly. There are two types, the system driver (e.g. "VGA" on an x86 PC, the kernel "console=" option); and the modular driver which can be loaded and unloaded as needed, and may take over the system driver. One possibly useful driver is netconsole, while it's readily loadable and un-loadable (it can be used as both a system and modular driver) there are two downsides:
- it doesn't
take_over_console() so everything still goes to the original console
- it only logs via ethernet (loopback is not supported)
You may be able to do something useful with the "dummy" console, and one of the options above.
socat make good "clients" for a netconsole:
modprobe netconsole "firstname.lastname@example.org/eth0,email@example.com/ff:ff:ff:ff:ff:ff"
socat UDP4-LISTEN:55514 -
If you're more interested in capturing console output from individual system services, then I don't think there's a simple way without script modifications.
Not-simple (and possibly not nice) ways of doing this include using LD_PRELOAD to
hijack redirect functions that generate output, or to add some
_init code to amend default file descriptors. Or worse: attaching with a debugger and manipulating the open file descriptors.
/etc/ld.so.preload would be a simple (if hackish and slightly nasty) way of implementing the first option.
If I wanted to monitor console output for daemons, I'd probably amend the startup scripts to run them in
screen sessions, perhaps like so.