Assura and NFS deleting old runs

[Rick]

Im having a problem with Assura not being able to delete the files from the
previous run. Assura get hunk up trying to delete, the process "rm" runs
continuously. All of the files are gone except the .nfsxxx files. Unix rm
has the same problem. How should NFS be set up so this does not happen? I
want to talk to our sys-admins but Im not sure what to ask them to do.

Thanks

Rick

 

[Bernd Fischer]

Yippieee,

I have the same problem and I'm in discussion with Cadence now since
3 Weeks.

See my previous posting:
http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&frame=right&th=79f7b3aea7512dfa&seekm=2q2nnvFqhaduU1%40

I detect some more:
- It's only with Assura 3.1.2 Hotfix1 or USR1 not with the
Assura 3.1.2 Base installation
- In our environment the lvs run files are on a Network Appliance file
server.
- It happens only for already LVS clean cells not for cells
where layout and schematic did not match.

Can you confirm this?

Today my local Cadence AE filed a Program Change Request for this
issue, even if they can not exactly reproduce this behaviour of Assura
the PCR No. is #746442.

I would appreciate it if you could tell your Cadence AE to append
to this PCR.

Replies direct to
bernd.fischer@xignal.com

Regards Bernd


Rick wrote:

Im having a problem with Assura not being able to delete the files from the
previous run. Assura get hunk up trying to delete, the process "rm" runs
continuously. All of the files are gone except the .nfsxxx files. Unix rm
has the same problem. How should NFS be set up so this does not happen? I
want to talk to our sys-admins but Im not sure what to ask them to do.

Thanks

Rick

 

[fogh]

Rick wrote:

Im having a problem with Assura not being able to delete the files from the
previous run. Assura get hunk up trying to delete, the process "rm" runs
continuously. All of the files are gone except the .nfsxxx files. Unix rm
has the same problem. How should NFS be set up so this does not happen? I
want to talk to our sys-admins but Im not sure what to ask them to do.
You can system-trace your rm (using truss, tusc, or strace) , and your sysadmin can watch the logs from NFS daemon (and related kernel stuff), after he set them to be most verbose.

 

[Bernd Fischer]

You can not do a truss on the rm
because the rm is here a child process of the
second Assura run where Assura itself is launched
from the UI out of the Design Framework.

We did a truss on icfb, but it does not help to
identify the problem.

Bernd

fogh wrote:

Rick wrote:

Im having a problem with Assura not being able to delete the files
from the
previous run. Assura get hunk up trying to delete, the process "rm"
runs continuously. All of the files are gone except the .nfsxxx
files. Unix rm
has the same problem. How should NFS be set up so this does not
happen? I want to talk to our sys-admins but Im not sure what to ask
them to do.

You can system-trace your rm (using truss, tusc, or strace) , and your
sysadmin can watch the logs from NFS daemon (and related kernel stuff),
after he set them to be most verbose.

 

[David Cuthbert]

Rick wrote:

Im having a problem with Assura not being able to delete the files from the
previous run. Assura get hunk up trying to delete, the process "rm" runs
continuously. All of the files are gone except the .nfsxxx files. Unix rm
has the same problem. How should NFS be set up so this does not happen? I
want to talk to our sys-admins but Im not sure what to ask them to do.

Thanks

Rick

..nfsXXXX files are "created" when you (or some process on your behalf)
remove a file which is opened by another process. They're placeholder
names which disappear automatically when the process is done using them.

It's quite possible that this is a bug in Assura.

There's a utility around called "lsof" (LiSt Open Files). It's
installed on most Linux distributions; for other OSes, you will need to
have your sysadmin install it. Typing "lsof /path/to/.nfsXXXX" (from
the client machine) should identify the culprit.

Dave

 

[Andrew Beckett]

I think it would get it if you do a truss -f which follows child
processes.

Normally .nfsxx files indicate that some application still has a file
open - it requires some sort of handle on the file if it gets deleted.
With local disk you can refer to a file via its inode, but an NFS
mounted disk requires a file name (I believe).

So almost certainly the problem is due to something not closing a file
when it should.

Andrew.

On Wed, 22 Sep 2004 14:45:21 +0200, Bernd Fischer
<""bernd.fischer\"@xignal-A%&HY%$v#&G=.de> wrote:

You can not do a truss on the rm
because the rm is here a child process of the
second Assura run where Assura itself is launched
from the UI out of the Design Framework.

We did a truss on icfb, but it does not help to
identify the problem.

Bernd

 

[fogh]

David Cuthbert wrote:

Rick wrote:

Im having a problem with Assura not being able to delete the files
from the
previous run. Assura get hunk up trying to delete, the process "rm"
runs continuously. All of the files are gone except the .nfsxxx
files. Unix rm
has the same problem. How should NFS be set up so this does not
happen? I want to talk to our sys-admins but Im not sure what to ask
them to do.

Thanks

Rick


.nfsXXXX files are "created" when you (or some process on your behalf)
remove a file which is opened by another process. They're placeholder
names which disappear automatically when the process is done using them.

It's quite possible that this is a bug in Assura.

There's a utility around called "lsof" (LiSt Open Files). It's
installed on most Linux distributions; for other OSes, you will need to
have your sysadmin install it. Typing "lsof /path/to/.nfsXXXX" (from
the client machine) should identify the culprit.

Dave
It could be "fuser" rather than "lsof". But if you have /proc filesystem

it makes thinks simpler. (is that a copyrighted corp motto?

 

[Bernd Fischer]

That's what Rick an I already discussed direct.

'lsof ./*' (list open files)
and you will see that icfb is keeping the LVS run files open.

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
icfb.exe 1901 bernd 9r VREG 255,1462 671 6592030 ./index
icfb.exe 1901 bernd 30r VREG 255,1462 221 6592031 ./stat
icfb.exe 1901 bernd 33r VREG 255,1462 954 6592032 ./extr
icfb.exe 1901 bernd 35r VREG 255,1462 671 6592030 ./index
icfb.exe 1901 bernd 36r VREG 255,1462 221 6592031 ./stat
icfb.exe 1901 bernd 37r VREG 255,1462 954 6592032 ./extr

Bernd

Andrew Beckett wrote:

I think it would get it if you do a truss -f which follows child
processes.

Normally .nfsxx files indicate that some application still has a file
open - it requires some sort of handle on the file if it gets deleted.
With local disk you can refer to a file via its inode, but an NFS
mounted disk requires a file name (I believe).

So almost certainly the problem is due to something not closing a file
when it should.

Andrew.

On Wed, 22 Sep 2004 14:45:21 +0200, Bernd Fischer
""bernd.fischer\"@xignal-A%&HY%$v#&G=.de> wrote:


You can not do a truss on the rm
because the rm is here a child process of the
second Assura run where Assura itself is launched

from the UI out of the Design Framework.

We did a truss on icfb, but it does not help to
identify the problem.

Bernd