|
From: Harish J. <ha...@te...> - 2012-01-12 09:10:18
|
Thanks Dave.
The thing is, due to some files under c:\usr\snmp\persist\mib_indexes,
it was causing my application to crash at snmp_init("myapps"). I am
loading mibs from
two directories. In persistent folder I found 4 index files which
suppose to be 2 as I am loading only two directories.
So, I deleted the folder c:\usr and restarted the application. It
created the c:\usr\snmp\persist\mib_indexes folder again with 2 files.
Then application seems to work fine.
I am wondering what could be the reason for crash and why it created 4
files at the first instance.
Please help me to understand.
Thanks
Harish
On 1/12/2012 1:56 PM, Dave Shield wrote:
> On 12 January 2012 06:01, Harish Jadhav<ha...@te...> wrote:
>> I have compiled netsnmp 5.7.1 for windows version
>> I am loading mibs from my application directory in the code using
>> setenv(mibdirs,path, 0) but it is creating the index files in
>> c:\\usr\snmp\persist directory.
> Yes - that is correct.
>
>> In ealier version, it is used to create the index in folders where mibs are
>> present( which is my appliation dir) but now it is creating a new directory
>> c:\\usr\snmp\persist.
> This change was introduced about five years ago (see SVN revision 15693)
> although the first release that used this approach was 5.5, which came out
> in mid 2009.
>
> The relevant log message is:
> "Maintain MIB directory index files under /var/net-snmp
> (in line with File Hierarchy Standard specifications)
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389434
> and discussion "MIBs in net-snmp" on coders list (Oct 2006)"
>
>
> The problem was that under Unix-style systems (which is the traditional
> focus of this problem), the MIB files could easily be present on a read-only
> partition, so it might not be possible to create the .index files there.
>
> Given that these files are only ever used by the library, which doesn't
> actually care where they reside - the cleanest solution was to move
> them to the persistent directory (which is necessarily writable).
>
>
>> How can I override this, please suggest.
> There's not really an easy way to change this.
> The simplest would probably be to set the persistent directory
> (either globally as Bart suggests, or within the application).
> If this is being done in a client application which has no real
> use for the persistent directory at all, then it *might* work to
> set the persistent directory to be on a non-existent drive, in
> which case it would simply fail to create the .index files at all.
> I haven't tested this, but it ought to work.
>
>
> Alternatively - what is the problem about leaving the index
> files in their new location? I know it's a change from the old
> (5.[0-4].x) behaviour, but does it really matter?
>
> Dave
>
>
>
--
Thanks& Regards,
Harish
|