On Sun, Dec 17, 2000 at 11:28:46PM -0600, Peter Samuelson wrote:
> [Mark Hahn]
> > > reinventing /proc/kmsg and klogd would be tre gross.
>
> [Lars Marowsky-Bree]
> > Well, only one process can read kmsg and get notified about new
> > messages at any time, so that makes the monitoring depend on
[Mark Hahn]
> > reinventing /proc/kmsg and klogd would be tre gross.
[Lars Marowsky-Bree]
> Well, only one process can read kmsg and get notified about new
> messages at any time, so that makes the monitoring depend on
> klogd/syslogd working, which given a write error by syslog might not
> be
On 2000-12-17T13:23:52,
Mark Hahn <[EMAIL PROTECTED]> said:
> > Short of parsing syslog messages, which isn't particularly great.
> what's wrong with it?
Because it means having to know about all potential messages the filesystems
might dump out.
> reinventing /proc/kmsg and klogd would be t
> currently, there is no way for an external application to monitor whether a
> filesystem or underlaying block device has hit an error condition - internal
> inconsistency, read or write error, whatever.
>
> Short of parsing syslog messages, which isn't particularly great.
what's wrong with it?
Good morning,
currently, there is no way for an external application to monitor whether a
filesystem or underlaying block device has hit an error condition - internal
inconsistency, read or write error, whatever.
Short of parsing syslog messages, which isn't particularly great.
This is necessar
5 matches
Mail list logo
