Re: Snmptrapd fails to read config after being sent 4096 SIGHUPs?

Joel Hansell <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <CAChT3ku9s7Pf4mpCbhYU65Lk6f7JERJnWgziUkSrt3EK9UmM4w@mail.gmail.com>
Hello,
I was unable to reproduce the problem on 5.7.1, so I assume that this was
already fixed. I'll upgrade our production installation to 5.7.2 as soon as
possible.
BR,
Joel Hansell


On Tue, Feb 4, 2014 at 3:09 PM, Joel Hansell <[email protected]> wrote:

> Hi again,
>
> As an update, I was able to reproduce the error by writing a script that
> issues 4096 HUP signals to snmptrapd. The process starts issuing the
> "maximum conf file count (4096) exceeded" error, and forgets the configured
> logging format.
> I don't suppose this is a known bug which was fixed some time after
> 5.6.1.1? It looks like an issue with the signal handling - there is only
> one config file, which is read multiple times. Seems like the config file
> counter should be reset when SIGHUP is received.
>  I can't find the source for 5.6.1.1, but in the 5.6.2 code, I don't see
> what the problem could be since "files" is in function-local scope. It
> should be zeroed every time the read_config() function is called. I guess
> there could be some scope confusion (or confusion on my part, I'm not a
> habitual C programmer), or the problem was already fixed in 5.6.2...
>
> I'm trying to reproduce the bug on 5.7.1 now, but unfortunately, since
> snmptrapd takes about a second to restart on SIGHUP, the test takes just
> over an hour to execure.
>
> BR,
> Joel Hansell
>
>
>
>
> On Tue, Feb 4, 2014 at 10:58 AM, Joel Hansell <[email protected]>wrote:
>
>> Hi list,
>>
>> Here's one I've been scratching my head over lately.
>>
>> We have a bit of an oddball solution, where we've got snmptrapd logging a
>> lot of traps into a file, which is parsed by an external tool. This is all
>> running on a HP-UX 11.2 system, with Net-SNMP version 5.6.1.1 delivered
>> with the "HP-UX Internet Express" package.
>>
>> A cron job runs "logrotate" every 15 minutes, and if the file is too big,
>> it's rotated, and the postrotate script issues a SIGHUP to snmptrapd. That
>> normally triggers the daemon to re-read its config and to restart the
>> logging into a new file.
>>
>> The snmptrapf.config is set up to use a particular one-line trap logging
>> format.
>>
>> It seems that every so often, the snmptrapd fails subtly on SIGHUP. It
>> only seems to happen after more than a couple of months have passed. 60
>> days, 91 days, 101 days, 113 days are some of the fault intervals.
>>
>> I've observed the following about the failure state after it happens:
>> - Snmptrapd is executing and logging traps
>> - The trap logging format has changed to the default trap logging format
>> (three lines per trap). This causes our parser to fail
>> - snmptrapd logs the error "[...]/snmptrapd.conf: line 0: Error: maximum
>> conf file count (4096) exceeded" at the start of the log file.
>>
>> The flow of traps is such that the log file is usually rotated every 30
>> minutes, but it goes up and down a bit. Could this failure be happening
>> after 4096 SIGHUPs? That would explain the varying time between failures.
>>
>> I'm grateful for any input.
>>
>> Regards,
>> Joel Hansell
>>
>>
>

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.