> Thoughts?
Agreed; this message just gets in the way in our application.
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix
On 2/10/11, Wes Hardaker wrote:
>> On Thu, 10 Feb 2011 15:01:32 +0100, Martin Buck
>> said:
>
> MB> I don't know what original problem that warning was meant to solve, but
> MB> wouldn't it be easier to just drop it?
>
> I agree, it's not too helpful. The discussion was from quite a whil
On Thu, 2011-02-10 at 08:40 -0800, Wes Hardaker wrote:
> > On Thu, 10 Feb 2011 15:01:32 +0100, Martin Buck
> > said:
>
> MB> I don't know what original problem that warning was meant to solve, but
> MB> wouldn't it be easier to just drop it?
>
> I agree, it's not too helpful. The discu
> On Thu, 10 Feb 2011 15:01:32 +0100, Martin Buck
> said:
MB> I don't know what original problem that warning was meant to solve, but
MB> wouldn't it be easier to just drop it?
I agree, it's not too helpful. The discussion was from quite a while
ago and I agree it's probably not worth
On Tue, Feb 08, 2011 at 09:42:31AM -0800, Wes Hardaker wrote:
> I ended up applying the first (the one that removes the call from the
> perl module itself). I agree it's redundant (now) to have it in there.
Thanks a lot!
> I think the proper thing to do would be to do this and also have command
> On Mon, 31 Jan 2011 16:50:10 +0100, Martin Buck
> said:
MB> finally, here are two proposed patches which remove mandatory logging to
MB> stderr in snmpd if it is using subagents implemented in Perl.
I ended up applying the first (the one that removes the call from the
perl module itse
Hi,
finally, here are two proposed patches which remove mandatory logging to
stderr in snmpd if it is using subagents implemented in Perl. snmpd now
redirects its stderr to /dev/null as one would expect from a normal daemon,
unless the user explicitly asks for stderr logging.
Both of the attached
