Environment
Novell Open Enterprise Server 1 (OES 1)
Novell Open Enterprise Server 2 (OES 2)
Novell Cluster Services 1.8.4
HP OpenView Storage Data Protector 5.5, 6.0, 6.1
Novell Open Enterprise Server 2 (OES 2)
Novell Cluster Services 1.8.4
HP OpenView Storage Data Protector 5.5, 6.0, 6.1
Situation
Running a backup job using HP Data Protector causes the server to crash.
The backup causes a faulty archiver ID to be set, and which causes the GUIDtoDN lookup to fail. The large amounts of failed GUIDtoDN lookups is to much for ndpapp to handle and hence causes ndpapp to crash
When new files are being copied to a volume we see the following archiver ID.
server:/home/user # grep archiver guid.txt
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
Next, we run a backup using Data Protector, we find archiver GUIDs similar as below.
server:/home/user # grep archiver guid.txt
<archiver><name><![CDATA[Unknown User]]></name><id>00000100-0000-0000-00-04-170022003200</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>01004c4c-0000-0000-00-00-000417002200</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>317e5845-422e-5441-00-01-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>48494e4d-7e45-2e31-45-58-450001000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>4558452e-0100-0000-00-00-000000041700</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>58452e31-0045-0001-00-00-000000000417</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>58452e31-0045-0001-00-00-000000000417</id></archiver>
It turns out that virtually all of the GUIDS are (or parts of) filenames and are bogus ID's :
For example :
3. guid=57494E324B2F434F4F4B4945532F3037
57494E324B2F434F4F4B4945532F3037 WIN2K/COOKIES/07
3. guid=38000000380000003A00000077000000
38000000380000003A00000077000000 88:w
3. guid=002C00340041002F6D656469612F6E73
002C00340041002F6D656469612F6E73 ,4A/media/ns
3. guid=767363695B325D2E7478740000000000
767363695B325D2E7478740000000000 vsci[2].txt
3. guid=767363695B325D2E7478740000000000
767363695B325D2E7478740000000000 vsci[2].txt
With OES2 SP1 the error also shows as OID_AddEntryIfNotThere - Unable to map GUID to DN using NCP eDir in /var/log/messages during the time frame when the backup is running
The backup causes a faulty archiver ID to be set, and which causes the GUIDtoDN lookup to fail. The large amounts of failed GUIDtoDN lookups is to much for ndpapp to handle and hence causes ndpapp to crash
When new files are being copied to a volume we see the following archiver ID.
server:/home/user # grep archiver guid.txt
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>00000000-0000-0000-00-00-000000000000</id></archiver>
Next, we run a backup using Data Protector, we find archiver GUIDs similar as below.
server:/home/user # grep archiver guid.txt
<archiver><name><![CDATA[Unknown User]]></name><id>00000100-0000-0000-00-04-170022003200</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>01004c4c-0000-0000-00-00-000417002200</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>317e5845-422e-5441-00-01-000000000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>48494e4d-7e45-2e31-45-58-450001000000</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>4558452e-0100-0000-00-00-000000041700</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>58452e31-0045-0001-00-00-000000000417</id></archiver>
<archiver><name><![CDATA[Unknown User]]></name><id>58452e31-0045-0001-00-00-000000000417</id></archiver>
It turns out that virtually all of the GUIDS are (or parts of) filenames and are bogus ID's :
For example :
3. guid=57494E324B2F434F4F4B4945532F3037
57494E324B2F434F4F4B4945532F3037 WIN2K/COOKIES/07
3. guid=38000000380000003A00000077000000
38000000380000003A00000077000000 88:w
3. guid=002C00340041002F6D656469612F6E73
002C00340041002F6D656469612F6E73 ,4A/media/ns
3. guid=767363695B325D2E7478740000000000
767363695B325D2E7478740000000000 vsci[2].txt
3. guid=767363695B325D2E7478740000000000
767363695B325D2E7478740000000000 vsci[2].txt
With OES2 SP1 the error also shows as OID_AddEntryIfNotThere - Unable to map GUID to DN using NCP eDir in /var/log/messages during the time frame when the backup is running
Resolution
A fix has been checked in to the 'libtsafs.so.0.0.52' module and has been released to the public.
Bug Number
352610
Additional Information
With this fixed module it is required to run a full backup.
The full backup ensures that all files that were previously populated with the bogus archiver GUID's are reset to 00000000-0000-0000-00-00-000000000000 again.
The full backup ensures that all files that were previously populated with the bogus archiver GUID's are reset to 00000000-0000-0000-00-00-000000000000 again.