BPJOBD process temporary workaround, for automation

I suspect you have more going on here related to either your operating environment or your hardware. Check your drive space. If the volume where /usr/openv is located exceeds 98% full Netbackup will shutdown to protect itself. Check your /var/adm/messages (case insensitive) for "sense|fail|fatal|error" and see if you get anything from the system. Netbackup doesn't just randomly decide to stop working. There's got to be a reason. Check your /usr/openv/netbackup/logs/ for indications as to why it's behaving like this.

I can't believe Symantec would reccommend you to upgrade to the next version while you're having this issue. They usually require you to resolve any conflicts before that to ensure the smoothest possible outcome.

Let me know how this works out for you.

Regards!

Hi LucSkywalker1957,

 Trust me I wasn't also very happy to see that suggestion but it was the 1st one. And checking the space and messages, I didnt find anything which should direct to this issue. I know there is a reason this is happening.

However 1 thing is the memory issue.

Linux 2.6.18-274.el5 (shnbupr01)        04/26/2013

04:38:47 PM kbmemfree kbmemused  %memused kbbuffers  kbcached kbswpfree kbswpused  %swpused  kbswpcad
04:38:49 PM    524140  32305908     98.40    645452  28494984   2096584       560      0.03         0
04:38:51 PM    521388  32308660     98.41    645452  28494992   2096584       560      0.03         0
04:38:53 PM    524008  32306040     98.40    645460  28495084   2096584       560      0.03         0
04:38:55 PM    523636  32306412     98.41    645464  28495092   2096584       560      0.03         0
04:38:57 PM    523760  32306288     98.40    645476  28495096   2096584       560      0.03         0
Average:       523386  32306662     98.41    645461  28495050   2096584       560      0.03         0

Not sure if this is normal for a heavily loaded master server.

Can you help me with that work around?

Thanks

Sid

Sometimes an upgrade is recommended for various reasons.

I do not know the details of this issue (apart from above) but unless there are exceptional circumstances (eg, totally unsupported system, overloaded system which we can't magically fix or similar) I do not believe you should be left without a solution.

1.  Reopen call.

2.  Explain that an upgrade is not acceptable

3.  If no luck, raise issue with duty manager

Martin

Thanks Martin for the suggestion, I would definitely reopen the case. However For the time being I need scripting expertise for my team to atleast not to start bpjobd every now and then till the issue is fixed.

So could someone help me with the script?

Thanks

Sid

Sure ... run this from cron every xx mins

Hi Martin,

Thanks for the script, Could you explain me few things because when I tried to use my logic and run the command with nohup it doesn't work.

nohup: appending output to `nohup.out' (this is what it says when I run your script and command prompt stays there is this normal or will it effect when it runs through crontab)

My script finds out if bpjobd is running or not and then it uses

But it doesn't work can you explain please.

Thanks

Sid

It would hang, until you press return.

I don't see this affecting it runing from cron, have you actually tried it ?

It won't do any harm, worst case is, it doesn't work.

(Apologies, I haven't had a chance to test it from cron).

If there are issues, the first thing I would try is remove the 'nohup' and try it from cron.

If I can find a linux box, I will test it, but above is the first thing I would do is as explained.

Martin

Hi Martin,

 Thanks for the reply.

I have tried the script without nohup before I started this blog. It doesn't work with crontab I tested it, We still had to start bpjobd manually. What would you suggest then.

Thanks

Sid

I'll try it on a server myself, see what's wrong with it.

Add full path to bpps in the posted script.  I don't see a problem with the bpjobd line.