e yet.
Bill
On Tue, Jan 9, 2024 at 1:58 AM Vivek Aditya wrote:
> Hi Team,
>
> I want the snmpv3 context to change without snmpd restart. When I checked
> with SIGHUP, looks like adding a new snmpv3 context, SIGHUP works; But
> deleting the context and sending a SIGHUP, the context
769
>
>
> On Mon, 8 Jan 2024 at 22:52, Wes Hardaker
> wrote:
>
>> Vivek Aditya writes:
>>
>> > I want the SNMP to start listening on a new agent port without restart.
>> > Just sending SIGHUP to snmpd does not work.
>> >
>> > Is there a
Hi Team,
I want the snmpv3 context to change without snmpd restart. When I checked
with SIGHUP, looks like adding a new snmpv3 context, SIGHUP works; But
deleting the context and sending a SIGHUP, the context does not get deleted
and still able to perform walk with that context.
Is there a way
. Any help or
suggestion is appreciated.
review link - https://github.com/net-snmp/net-snmp/pull/769
On Mon, 8 Jan 2024 at 22:52, Wes Hardaker
wrote:
> Vivek Aditya writes:
>
> > I want the SNMP to start listening on a new agent port without restart.
> > Just sending S
Vivek Aditya writes:
> I want the SNMP to start listening on a new agent port without restart.
> Just sending SIGHUP to snmpd does not work.
>
> Is there a way to do it or has this issue already been fixed? Any help
> would be appreciated.
That's a good feature request,
Hi Team,
I want the SNMP to start listening on a new agent port without restart.
Just sending SIGHUP to snmpd does not work.
Is there a way to do it or has this issue already been fixed? Any help
would be appreciated.
--
Warm Regards,
Vivek Aditya
Hi All,
Updated engine-id is not being re-read after sending SIGHUP to snmpd.
I am performing a snmpwalk with '-e' engine-id. After changing the
engine-id and sending a SIGHUP to snmpd, I was expecting snmpwalk with the
previous engine-id to fail while snmpwalk with the updated engin
Hi,
After restart snmpd using SIGHUP, agentadress is not updating. I don't find
any code to reinit master agent.
Is there have fix for it?
Regards
Paban
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
files in my application code, and sending snmpd
a SIGHUP to have it reload its settings.
This would be for a fixed version of Net-SNMP as v5.7.1, so I recognize that
the content of the
configuration files may change with differing versions.
It is very desirable for the snmpd to remain
> On Thu, 23 Apr 2009 12:23:04 -0700, Tushar Gohad said:
TG> Thanks Wes for the acceptance. I was under the impression that I need
TG> to get the approval here before I submit the patch on
TG> net-snmp.org/patches. Will submit to both the places the next time. :)
The patch tracker is in
Thanks Wes for the acceptance. I was under the impression that I need
to get the approval here before I submit the patch on
net-snmp.org/patches. Will submit to both the places the next time. :)
- Tushar
Wes Hardaker wrote:
>> On Fri, 17 Apr 2009 08:26:13 -0700, Tushar Gohad
>> s
> On Fri, 17 Apr 2009 08:26:13 -0700, Tushar Gohad said:
TG> Any comments on the patch below?
Sorry for the delay... We tend to be busy a lot of the time and can't
quickly respond to every patch (which is often because the right
person(s) knowledgeable about that particular code body is not
Folks,
Any comments on the patch below? Without the patch, traps for events
such as linkup/down are seen multiple times upon reconfig on SIGHUP.
Many thanks,
- Tushar
Tushar Gohad wrote:
> On a SIGHUP, clear_mteTTable() clears trigger_table_data but the
> mteTrigger entries
On a SIGHUP, clear_mteTTable() clears trigger_table_data but the
mteTrigger entries remain registered in the POST_READ_CONFIG callbacks
table. This causes multiple trap notifications for the same event when
a SIGHUP is issued to snmpd.
The patch below makes sure that the callbacks for the
Hi Fong,
About your issue: SIGHUP on net-snmp-coders, could I ask you some questions?
Your help will be appreciated!
>>Also, if you remove the configuration entry, it doesn't work either.
>>
>>-Original Message-
>>From: Fong Tsui
>>Sent: Wednesd
Also, if you remove the configuration entry, it doesn't work either.
-Original Message-
From: Fong Tsui
Sent: Wednesday, November 21, 2007 12:12 PM
To: Fong Tsui; 'net-snmp-coders@lists.sourceforge.net'
Subject: RE: SIGHUP
I found that it doesn't work if you add the
bject: SIGHUP
Hi, everybody,
I am trying to use "SIGUP" to re-load the configuration instead of
restarting snmpd. It seems some of configuration is reloaded correctly
but some of them are not.
When I comment out rocommunity entry in snmpd.conf and do "killall -HUP
snmpd", I ca
Hi, everybody,
I am trying to use "SIGUP" to re-load the configuration instead of
restarting snmpd. It seems some of configuration is reloaded correctly
but some of them are not.
When I comment out rocommunity entry in snmpd.conf and do "killall -HUP
snmpd", I can see log message:
snmpd[6458]:
try to set the locally
implemented object, the operation is successful for
valid data. The set operation adds a new user entry
into the snmpd.conf file and internally sends a SIGHUP
to the UCD Master Agent. Even other GET* queries to
the agent goes through successfully immediately after
the SET
Dominique bastien wrote:
> I perform some tests yesterday with the SIGHUP feature
> and I notice that the lines in snmpd.conf containing
> the "override" keyword are not process at the
> warm-boot.
Please file a bug on http://www.net-snmp.org/bugs .
Please provide syste
I perform some tests yesterday with the SIGHUP feature
and I notice that the lines in snmpd.conf containing
the "override" keyword are not process at the
warm-boot.
What is missing to make this thing work properly?
Do we have to register a callback or add something in
update_config(
Guddenahalli Naganna, Jayaprakasha wrote:
> The main problem is in real_init_master(), we free agentx_sockets which
> is netsnmp_ds_strings[1][1] but we never reset netsnmp_ds_strings[1][1]
> to 0. Later on, we calloc an slp which has the same ptr as
> netsnmp_ds_strings[1][1] & add the slp to t
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guddenahalli Naganna, Jayaprakasha
Sent: Wednesday, May 31, 2006 1:06
PM
To: net-snmp-coders@lists.sourceforge.net
Subject: SNMP Daemon crashed on
sending SIGHUP signal by deleting trap2sink entry from configuration file.
Net-snmp ver
agentaddress 161
4. Send SIGHUP to master agent
Now snmp daemon will crash. Crash is consistent only with the above procedure.
Here is the gdb trace,
[EMAIL PROTECTED]:/nh/bin# gdb -d .. master_agent
GNU gdb 6.0 (MontaVista 6.0-8.0.7.0300532 2003-12-24)
Copyright 2003 Free
agentaddress 161
4. Send SIGHUP to master agent
Now snmp daemon will crash. Crash is consistent only with the above procedure.
Here is the gdb trace,
[EMAIL PROTECTED]:/nh/bin# gdb -d .. master_agent
GNU gdb 6.0 (MontaVista 6.0-8.0.7.0300532 2003-12-24)
Copyright 2003 Free
I've found a fix for the sighup bug (see bug report at
https://sourceforge.net/tracker/index.php?func=detail&aid=1473289&group_id=12694&atid=112694),
and propose that we push throught 5.3.0.2 asap to fix this. snmpd is a long
running process, relying on logrotate to manage log fil
-Coders,
I've just submitted patch #1225440 that fixes snmpd and snmptrapd to not
terminate on an "early" SIGHUP. Please see:
http://sf.net/tracker/index.php?func=detail&aid=1225440&group_id=12694&atid=312694
I'd love to see this go in before releasing 5.
-Coders,
"Patches speak louder than emails." [RS] -- let's have a try.
Thomas> However, version 5.1.2 effectively duplicates the traphandler
Thomas> registrations on every SIGHUP!
Wes> Yes, we need to write a proper free function for all the
Wes> registrations...
Wes&g
On Tue, 19 Oct 2004 10:28:05 +0200 Thomas wrote:
TA> Thomas Anders wrote:
TA> > Just filed bug 1040711 for this.
TA> >
TA> > If anyone can give me some hints on how to best find and remove a
TA> > traphandler
TA> > from the authentication/pre-specific/trap-specific/global lists, I'd be
TA> > wil
Thomas Anders wrote:
Just filed bug 1040711 for this.
If anyone can give me some hints on how to best find and remove a
traphandler
from the authentication/pre-specific/trap-specific/global lists, I'd be
willing
to work on a proper fix.
Is anyone working on this? As I said, I'm willing to tackle
Thomas Anders wrote:
Yep, that's it. apps/snmptrapd_handlers.c in both CVS MAIN and V5-1-patches
does *not* define an appropriate free function:
Just filed bug 1040711 for this.
If anyone can give me some hints on how to best find and remove a traphandler
from the authentication/pre-specific/trap-s
Wes Hardaker wrote:
On Sat, 02 Oct 2004 00:38:31 +0200, Thomas Anders <[EMAIL PROTECTED]> said:
Thomas> However, version 5.1.2 effectively duplicates the traphandler
Thomas> registrations on every SIGHUP!
Yes, we need to write a proper free function for all the
registrations...
Ye
>>>>> On Sat, 02 Oct 2004 00:38:31 +0200, Thomas Anders <[EMAIL PROTECTED]> said:
Thomas> However, version 5.1.2 effectively duplicates the traphandler
Thomas> registrations on every SIGHUP!
Yes, we need to write a proper free function for all the
registrations...
-Coders,
upon receiving SIGHUP, snmptrapd rereads its configuration file(s)
which can be quite useful.
However, version 5.1.2 effectively duplicates the traphandler
registrations on every SIGHUP! I.e. after sending SIGHUP n times,
a single trap triggers the corresponding traphandler n times!
A
34 matches
Mail list logo
