why are perms for /dev/async changing, need to keep them at 600

[wvsa]

Good morning all;

We are in the process of running upgrading our oracle ebs database on a 11iv3 rx6600 server. We are using cooked file systems so no need for /dev/async. We are having problems during the upgrade process; something keeps changing the perms on /dev/async to 666 which causes problems during our ebs upgrade process. Does anyone know why the perms for /dev/async keep changing and how we can keep the perms at 600

Thank you for your assistance

Norm

[T G Manikandan]

Are you trying to add hardware to the system.insf -e might reset the permissions of this file.

By default the permissions are 660 oracle:dba

[T G Manikandan]

can you keep running lsof -p and check if its calling up the /dev/async.

[wvsa]

Good morning;

I think you maybe onto something with your first response, believe one of the admins added a tape library to the box yestorday and ran insf -e.

We don't want oracle to be aware of /dev/async so we would like to keep the owner root:sys with perms 600.

What is causing insf -e to change the perms on /dev/async.

Thank you for your responses!

[T G Manikandan]

If you read the man pages of insf you can notice that running insf would create async file and change permissions.
And ofcourse the async driver enabled in the kernel insf tries to re-install the file.

With the permissions being root:sys I dont think the oracle process owned by oracle user can reset its permissions.

One way to think about is disabling the async driver on the kernel so that you wouldn't be worried much.

[Duncan Edmonstone · Accepted solution]

TG's approach is probably the best bet

kcmodule asyncdsk=unused

followed by a reboot should get rid of the async disk driver and /dev/async

HTH

Duncan

[wvsa]

All;

Thank you for your responses, will disable the /dev/async driver.

Thanks again for your help