EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: log message filter in Asyn
From: <matthew.pearson@diamond.ac.uk>
To: <benjamin.franksen@helmholtz-berlin.de>, <tech-talk@aps.anl.gov>
Date: Wed, 18 Apr 2012 18:51:02 +0000
Hi,

The problem is is that we already have loads of drivers issuing messages that they shouldn't do, so it would be good to have a solution that doesn't involve modifying these. True, lots of the messages should be only printed once. But there is a case for a driver repeating some kinds of message at some slow rate, to inform the terminal that 'something is still not right'. This gets round the problem of a single message being lost due to some other printout going on. 

I think the linux kernel provides simple rate limiting on kernel printk messages, although I think that's more to do with dealing with the case where the developer isn't sure how frequently the message could be printed.

Cheers,
Matt

________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Benjamin Franksen [benjamin.franksen@helmholtz-berlin.de]
Sent: 18 April 2012 15:04
To: tech-talk@aps.anl.gov
Subject: Re: log message filter in Asyn

On Wednesday, April 18, 2012, matthew.pearson@diamond.ac.uk wrote:
> > One simple idea would be to add a bit to the asynTrace flags,
> > ASYN_TRACE_NOREPEATS.  The asynTrace facility could remember the
> > previous error message for a particular pasynUser, and if the next one
> > is the same (except for the time stamp) then the message would not be
> > output.
>
> The drivers would then need to decide when to reset that flag, to print
> the message again. For example, if a comms error was resolved, but
> re-occurred again (say, an hour later). You would want a new message in
> that case.
>
> Seems like, in general, people wouldn't mind this functionality in the
> errlog layer. Perhaps as Nick suggested as a library that implemented
> the same interface, and was plugged in somehow. Or, could modify errlog
> by adding a function call in each function, that checks the message and
> rejects or accepts it.

Errlog is /not/ the right place to ensure error messages are issued in a
sensible way. Generic filtering of messages is too weak, it cannot know
which messages are important and which are not. It cannot decide which
errors are merely consequences of something at a lower level going wrong. It
is also very inefficient to filter messages that should not be issued in the
first place.

It is the driver that knows whether a port is disconnected. It can and
should report this exactly once. It can and should report, again only once,
when the port is connected again. Device support should /not/ issue an error
message if a lower level (i.e. driver) indicates that it already did so.

Note I am not talking about special debugging support. This is for normal
operation, where you do /not/ want log files to increase to Gigabytes in a
few days, simply because someone pulled a plug or forgot to switch on some
seldom looked at device after maintenance.

Cheers
Ben

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 





Replies:
Re: log message filter in Asyn Andrew Johnson
References:
log message filter in Asyn matthew.pearson
RE: log message filter in Asyn Mark Rivers
RE: log message filter in Asyn matthew.pearson
Re: log message filter in Asyn Benjamin Franksen

Navigate by Date:
Prev: Re: log message filter in Asyn Benjamin Franksen
Next: Re: log message filter in Asyn Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: log message filter in Asyn Benjamin Franksen
Next: Re: log message filter in Asyn Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020