>On Fri, 7 Oct 1994, Darren Reed wrote:
>
>>
>> Hmmm...has anyone managed to have syslog send data directly to a laser
>> or any other sort of non-line printer ? :-)
>
>I have not tried, but if you specify logging to a file in your
>syslog.conf, make that a named pipe and have a process reading from it
>on the other end and have that program queue it up for a line printer
>it may work.
>
>Or if you want to do it the simple way, hook up a printer to /dev/ttyx
>and specify /dev/ttyx as the log file in the syslog.conf file.
It's easy to have a process spewing info to syslog a lot faster than
most printers could keep up with. I don't know the details of syslogd
implementation, but it seems that bad things could happen, like losing
logging info, or syslogd blocking on a write(2) while waiting for the
device to accept more input.
It would be best to use a process that could have sufficient queueing
capacity for incoming messages. It ought to be fairly easy for a
motivated person to create a syslogd replacement (brand new or modify
the available source) to run on the logging system that could be
intelligent about receiving vast amounts of info and logging it to a
printer or other device (tape, worm, etc.), queueing the backlog while
the output device catches up. (I don't really know how unintelligent
the existing daemons are or are not about this, not having investigated
the implementations.)
Of course, no implementation will have an infinite amount of queue
available for backlog caching; without gigabytes of fast storage, it's
probably impossible to guard against the gigabyte Denial Of Service
dump without losing some of the info.
|
|
