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 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
>
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
> 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
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
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
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?
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 tre
9 matches
Mail list logo
