bpgetdebuglog case sensativity issues

[Mark_Garringer]

I have a 7.5.0.4 linux master and a 7.5.0.4 Windows 2k3 client.

I can use the command: bpgetdebuglog <client> bpcd 120512 successfully.

I cannot use the command: bpgetdebuglog <client> bpbkar 120512 successfully.

Checking on the client to make sure the bpbkar log folder exists (it does) I noticed that the file is called 120512.LOG in bpbkar, not 120512.log as it is in bpcd.

How can I either a) change the LOG to log behavior or b) make bpgetdebuglog not be so case sensative?

Thanks!

[revarooo]

Have you tried copying the file to a lower case .log? Does that work? If so, perhaps a bug in the way 7.5.0.4 is naming the log files for bpbkar ?

[Mark_Garringer]

Oh good point revaroo, I forgot to include. If I rename the file to 120512.log it works as expected.

[revarooo]

Hmm interesting. Try deleting the log and run a quick test backup to that client, does it recreate the log with uppercase .LOG again?

Is it logging all Win2003 clients at 7.5.0.4 with uppercase bbkar .LOG files?

[mph999]

I'm not aware that the case is 'adjustable'.

Is it possible that it was manually changed ?

In fact, I am goiong to stick my neck out and say it has.

1.  The log names are lowercase

2.  The log name is this format, log.<date>, not <date>.log

Interestingly, I rename my bpbkar log for today to <date>.log and the bpgetdebuglog command still worked, so it must just search on the date, not the file name format (probably by design).

Could it be a bug - we must always consider the possibility ... but ...

1. I am running nbu 7.5.0.4, and therefore the same code as you and mine works fine.

2. If it was a bug, we'd probably know about it and checking the eTracks I don't find it supported.

I think all will become clear when you run a test, if the log has the format log.<date> then the most likely cause, based on what we know at the moment is that it was renamed manually.

Martin

[Mark_Garringer]

The original bpbkar (and bpcd) logs were created on demand for my initial testing. Nothing manual took place.

I have removed the 120512.log from bpcd, the 120512.LOG from bpbkar and just created a vnetd folder. I have started my backup and now have 3 files. bpcd/120512.log bpbkar/120512.LOG and vnetd/120512.log

Better yet, I picked a different 2003 client at random which is running 6.5.3.1 and did the same thing. Created bpcd, bpbkar and vnetd folders, started a backup and got the exact same results. The bpcd and vnetd logs are 120512.log and the bpbkar is 120512.LOG. I can bpgetdebuglog the first 2 but not the 3rd.

Screenshot from the 6.5.3.1 test client.

[revarooo]

Seems like we have a potential bug on our hands. You need to log a call with Symantec and report this. Give them examples of your tests cases then they can try and reproduce and escalate for a fix.

Seems this guy had a similar issue with bpgetdebulog with bpbkar on Windows 2000 client

https://www-secure.symantec.com/connect/forums/what-type-client-logs-can-bpgetdebuglog-retrieve-client

[mph999]

Indeed, looks like you find a bug - oh well, you win some, you lose some ...

Main thing is we can now look into it with the evidence from the test.

Odd, as it doesn't seem to care if log.<date> or <date>.log, but does care about the case.

Question now, is what log do you get when the logs don't work ...

Hold up on that, I'm kidding ...  

I suggest downloading process monitor (google will find it) so you can run a 'truss' on the bpbkar process to see exactly what it is doing, might be needed as evidence.

I honestly am amazed we don't seem to have seen this before (considering the number of logs support look at each day ...)

Regards,

Martin

[revarooo · Accepted solution]

Ok I've just reproduced this on a Windows 2003 client with NetBackup 7.0.1.

I can get the bpcd log no problem but the bpbkar log is created with an uppercase .LOG and I cannot get this with bpgetdebuglog from my master server unless I rename the .LOG to .log.

 This IS a confirmed bug now with bpbkar32.exe on Windows. Please log a call with Symantec if you want this issue resolved.

[Mark_Garringer]

I am doing that now, thanks guys!

[revarooo]

Mark, was an interesting little test and experiment. Good troubleshooting work on this, one that has not been picked up before, or at least not tested extensively and reported.

Please mark the post that helped the most as "marked solution" as there is not much more we can do on the forum. Support and Engineering from Symantec should be able to assist you forward and I bet they will be surprised this bug has not been captured before.

Take care.

[mph999]

Unless it has been seen before, and we just can't find the eTrack ...

Then again ... I would bet that not that many people run the command, on the bpbkar log that is on a windows server at that version of NBU ....

Martin