cadence question
Xiaofeng Wang
i guess it is due to some file is locked. but how shall i solve it?
Thanks.
Xiaofeng
Bernd Fischer
Delete the files 'CDS.log.cdslck' and 'CDS.log' in your $HOME directory.
In general Cadence DFII open for every session you run in parallel a
new 'CDS.log' file, e.g. first session 'CDS.log' second session 'CDS.log.1'
and so on.
If you exit normally the lock file 'CDS.log.cdslck' will be removed
automatically
and the log file 'CDS.log' will be overwritten the next time you start a DFII
session.
If you exit with a crash the lock file sometimes stays and the next time you
start a DFII session, DFII is not able to overwrite the log file 'CDS.log' and
opens a new one 'CDS.log.1'.
This is nothing to worry about, normal behaviour.
Bernd
Pete nospam Zakel
>> when i start cadence, i find the log is ..../cds.log.1, instead of .../cds.log.
>> i guess it is due to some file is locked. but how shall i solve it?
>Delete the files 'CDS.log.cdslck' and 'CDS.log' in your $HOME directory.
>In general Cadence DFII open for every session you run in parallel a
>new 'CDS.log' file, e.g. first session 'CDS.log' second session 'CDS.log.1'
>and so on.
>If you exit normally the lock file 'CDS.log.cdslck' will be removed
>automatically
>and the log file 'CDS.log' will be overwritten the next time you start a DFII
>session.
>If you exit with a crash the lock file sometimes stays and the next time you
>start a DFII session, DFII is not able to overwrite the log file 'CDS.log' and
>opens a new one 'CDS.log.1'.
Actually, if the CDS.log.cdslck file exists but the process that created it
no longer exists, then the lock is removed automatically when the next process
tries to lock the file.
More likely the problem is lack of permission to delete the CDS.log and or
the CDS.log.cdslck file.
-Pete Zakel
(p...@seeheader.nospam)
"In English, every word can be verbed. Would that it were so in our
programming languages."
Andrew Beckett
Bernd).
This is all related to how stranded lock recovery works. Let me outline that
for both the old (cdsd) locking system, and the new (CLS) locking system.
For cdsd based locking, a daemon (cdsd) runs on each file server, or
if that file server is not a supported platform (Solaris, HPUX, IBM AIX),
then it runs on another server using the proxy mechanism.
When a file is locked, it registers an interest with that daemon, and this
daemon records that the file is locked (for edit or for read). When the
software exits normally, it tells cdsd that it no longer has an interest in
that file, and the lock gets removed. If the software exits abnormally,
then this is found by the lock daemon's regular check to each locking
process, generally within 5 seconds of the crash (at least this has been the
behaviour for any cdsd version in the last few years). If however the
process is still alive and well, then the lock remains (fair enough).
In IC445, cdsd based locking was replaced with CLS, which uses a
"lock-stake" file to record the lock information. The idea is that when
a file needs to be locked (only for edit now, since the concept of
read locks was removed - primarily because they were inconvenient and
not universally applied by all tools), a side file with the extension .cdslck
is written with information about the locker. This eliminates the need for
daemons on file servers, or proxies for unsupported file systems, and
simplifies the locking system enormously.
In IC445 and IC446, the default was to operate both locking systems
in parallel (to allow for older releases to access the libraries without
fear of edit clashes) - although there would never be any read locks
in cdsd any more. You could elect to turn off cdsd and just use
CLS if you wanted (no point running cdsd if it wasn't needed). In IC50,
since no cdsd-based release is supported any more, the default has changed
to be CLS only.
OK, so now what happens when the software exits normally? The cdslck
file will be removed, so that next time the software starts up, it will quite
happily be able to lock the file again.
What happens if the software exits abnormally? The cdslck file may
remain (depends on if it managed to do any cleanup on the way out),
and if so, when the next process tries to lock that file, it has to go through
a procedure to try to recover the stranded lock.
In the cdslck file there is (or should be; more later) information about the
machine on which the lock occurred, and the process id (as well as some
other adminstrative information). What the client that is trying to lock
the file needs to do is determine whether the process is still running
on that machine; if not then it is safe to reclaim the lock. If it can't find
out, or if the process is still running, then the lock remains.
In order to find out whether a process is still running, the locking system
relies on a little daemon called "clsbd" (CLS boolean daemon) which simply
returns a true/false indication of whether the process is still alive. This
needs to run on any machine which runs Cadence (at least DFII) software,
and will be automatically started by DFII if it is not running already. If the
clsbd is not running for a machine which previously had a lock, then
it will not be able to determine if the process is still alive, and so the lock
will remain. Usually the reason for clsbd not running is because a machine
crashed, or was rebooted, and clsbd hasn't restarted yet - so it's a good idea
to launch it during the startup of any machine which could potentially run
Cadence software.
So, provided that clsbd is running, and the networking is behaving, then
stranded locks should be recovered.
Now, this leads us to why might it still be locked?
1. The process which had the lock might still be alive - in which case the
lock is valid
2. The clsbd on the locking machine might not be running any more.
Restart it - and ensure that it starts at boot time.
3. The machine which had the lock is no longer on the network (it
has gone off to be repaired, say). This is one of the very rare cases
that it is reasonable to remove a lock. You can use clsAdminTool
to search for and remove lock files. Or use rm.
4. Somebody tarred up a directory containing lock files, and then transferred
them to a different network (we see this quite commonly with testcases).
Again, since the locking machine doesn't exist, it can't recover the stranded
lock, and you'll need to remove the lock.
5. The disk filled up during a previous lock attempt, and it created the cdslck
file, but empty. There is a PCR for this (it might have been fixed now - the
fix is to remove the empty lock file if it runs out of disk whilst creating
it). The problem here is that it doesn't know which machine had the lock,
so it plays safe and doesn't allow the lock to be recovered.
6. Another possibility is that the cdslck file can't be removed, but that's
unlikely because it would suggest that the directory containing the lock
file was not writeable (or perhaps had the "t" bit set, and was owned by
someone else). If it wasn't writable, it wouldn't be able to create a CDS.log
file at all (with any numbered suffix).
There is also the rare case where the file server doesn't handle OS locks
(effectively lockd style locks). These are used to protect the lock file whilst
it is being locked. If that happens though, generally the software will
hang or take a very long time to fail to come up. That can be
controlled by an environment variable DD_DONT_DO_OS_LOCKS (set
to anything I think), but that's almost certainly not the problem here.
I'd check through the list above.
All in all, in a properly set up environment with the new locking system, you
should not have to remove lock files with the rare exception of a machine no
longer being available.
You're probably sorry you asked after all this ;->
Best Regards,
Andrew.
On Wed, 18 Dec 2002 17:47:12 +0100, Bernd Fischer <bernd....@xignal.de>
wrote:
--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd
Bernd Fischer
thanks for that good explanation, I copied it to my
folder of good explanations ;-).
> Actually it is not normal behaviour to need to delete these files (sorry
> Bernd).
As you may know I'm not native english, what I meant with
'normal behaviour' was not that DFII does this all the time,
but that this may happen from time to time after a crash.
Now we know exactly why.
The easiest way to get rid of it if you have a stranded lock on
the CDS.log file in my opinion is to delete the CDS.log.cdslck,
correct me if I'm wrong.
There is a more elegant way to remove a stranded lock, from the
clsbd daemon, with the 'clsAdminTool', which I usually use for
stranded locks on data files (layout and schematic views), but
if I had a stranded lock on the CDS.log I straightly delete the
CDS.log.cdslck.
Bernd
Andrew Beckett
By "normal behaviour" I meant that you should not have to delete these
manually in the vast majority of situations, if everything is set up correctly.
The first priority should be to check that the clsbd is running correctly.
Then to check that the process is not still running.
Then finally to delete the lock file by hand (either using rm or clsAdminTool).
All I was really trying to say by giving my detailed reply was that the number
of occasions when you should need to restort to manual deletion are
very few - only when the machine is no longer accessible on the network.
One other reason why it can happen is one that I saw at a customer
recently - they had the port for clsbd blocked on their compute servers. There
wasn't any particular thinking behind this, just that nobody had questioned the
fact that the stranded lock recovery didn't work and were manually deleting lock
files themselves (and in their case were removing perfectly valid locks at
the same time, which is asking for databases to get corrupted or at least
design data lost).
Regards,
Andrew.
On Thu, 19 Dec 2002 12:10:07 +0100, Bernd Fischer <bernd....@xignal.de>
wrote:
>Andrew,
--
Erik Wanta
We delete cdslck files all day long (find . | grep cdslck | xargs rm).
If icfb crashes or we have to kill it ungracefully we can't open up
views because of these files and instead get asked if we want to open
for readonly. As far as I know, everything is configured correctly
(we have no problems (the cdslck files are removed) if icfb exits
gracefully.
You mentioned checking to make sure clsbd is running correctly. It is
running, is there a test I can do to make sure it is running
correctly?
You mentioned that one possible reason could be a blocked port.
Please describe how I can determine if this is the case?
---
Erik
Andrew Beckett <and...@DELETETHISBITcadence.com> wrote in message news:<kmj30v0v0de7f2ro2...@4ax.com>...
Andrew Beckett
Well, clsbd is a very light process - there's not much that can go wrong
with it.
The default port number is 16723. You can change it (but you must change it
everywhere) with the environment variable CLS_PORTNUM.
Do a search for clsbd in cdsdoc for more details.
If you try doing:
telnet machineName 16723
then if the port is not blocked, it will return something like:
Trying...
Connected to mymachine.
Escape character is '^]'.
ClsBoolVersion 1
When I hit return - I get this:
BAD-MESSAGEConnection closed by foreign host.
(because I'm not talking to it properly, but it is still responding).
If instead you got something like:
Trying...
telnet: Unable to connect to remote host: Connection refused
when you tried to connect, it suggests that either clsbd isn't running
on that machine, or the port is blocked. Note, you'll have to do this
from a different machine to the one you're running on (i.e. I expect
locks get recovered if the lock was on the same machine).
Also, the other thing to look at is if you are running in compatibility
mode - are you running an old version of cdsd on the file server?
Locks only get recovered if it can recover in both cdsd and cls.
Old versions of cdsd tend to hold on to locks rather longer than
they should. Also, consider if you actually need to run in compatibility
mode.
Regards,
Andrew.
--
John Gianni
> We delete cdslck files all day long (find . | grep cdslck | xargs rm).
1. FYI I filed, on 10-22-2002, a Product Change Request 483238
titled:
"Request clsAdminTool UNIX lock-detection & removal command"
which, when completed, should provide the simple commands:
csh% clsAdminTool -findlck
csh% clsAdminTool -cleanlck
csh% clsAdminTool -reportlck
(If you would like your opinion appended to the PCR, please send
me a paragraph or two which I will gladly add to the PCR to bolster
the argument that the Customer desires these improvements.)
2. This would be better than wrapping clsAdminTool in a (kludgy)
shell script such as:
csh% vi $HOME/bin/clsAdminScript
#! /bin/csh -f
# alias findlck "clsAdminScript ale ."
# alias cleanlck "clsAdminScript are ."
set CMD_FILE = /tmp/admin.script$$
echo $* > $CMD_FILE
echo quit >> $CMD_FILE
clsAdminTool < $CMD_FILE
rm -f $CMD_FILE
exit 0
csh% alias findlck "clsAdminScript ale ."
csh% alias cleanlck "clsAdminScript are ."
Which works something like:
csh% clsAdminScript ale .
> BEGIN: Edit Locks List
> ./fileA machine.Domain.COM 2087 1035246101
> ./dir1/fileB machine.Domain.COM 2169 1035247108
>END: Edit Locks List
And:
csh% clsAdminScript are .
> BEGIN: Release Edit Locks.
> ./fileA machine.Domain.COM 2087 1035246101
> ./dir1/fileB machine.Domain.COM 2169 1035247108
>END: Release Edit Locks.
>SUMMARY: A total of 2 Edit Locks were released ...
3. The intent is to be better than the (much less attractive)
(yet more obvious) UNIX-command-line alternative:
csh% findlck
Where findlck is defined as:
alias findlck "find . -name '*cdslck*'"
And
csh% cleanlck
Where cleanlck is defined as:
alias cleanlck "findlck | xargs /bin/rm"
Note: The xargs eliminates cshell too-many-files errors.
Or:
find . -name '*cdslck*' -exec rm {} \;
And
csh% reportlck
Where reportlck is defined as:
alias reportlck "findlck | xargs /bin/cat"
The point is that clsAdminTool 'understands' more about lock files
than does UNIX, per se; so, these suggestions above for detecting,
reporting, and removing stranded lock files may be useful to some
on comp.cad.cadence until/unless the PCR mentioned above is successfully
implemented. (Send me your needs in a paragraph or two and I'll gladly
append them to the PCR to lend weight to the Customer need.)
--
All my USENET posts are PERSONAL opinion ... not company statements!
I do not read email at this address (it is for anti-spam purposes).
Erik Wanta
The port is not blocked.
cdsd is running and is version:
cdsd -version
@(#)$CDS: cdsd version 4.4.3 09/21/2000 03:18 (cds230) $
We are setting CLS_CDSD_COMPATIBILITY_LOCKING NO in the environment files for 445+.
Shouldn't the above setting prevent conflict with cdsd?
We do run 443 and 434 to resimulate old designs on occasion.
---
Erik
Andrew Beckett <and...@DELETETHISBITcadence.com> wrote in message news:<5b6c0vc1386u6g069...@4ax.com>...
Andrew Beckett
Have you tried using the DD_DONT_DO_OS_LOCKS env var I mentioned before?
Also, try this debugging variable:
setenv DD_DEBUG_NEWLOCK 1
(set it to 2 or 3 to get more output) and you should see messages in the CIW
or Library Manager log giving more info. Probably you only want to set this when
you have an example of a stranded lock.
You're right - setting CLS_CDSD_COMPATIBILITY_LOCKING to NO means that it will
not be using cdsd - so that rules out a conflict with cdsd.
Regards,
Andrew.
On 23 Dec 2002 03:25:40 -0800, erik...@starband.net (Erik Wanta) wrote:
>Andrew:
>The port is not blocked.
>
>cdsd is running and is version:
>cdsd -version
>@(#)$CDS: cdsd version 4.4.3 09/21/2000 03:18 (cds230) $
>
>We are setting CLS_CDSD_COMPATIBILITY_LOCKING NO in the environment files for 445+.
>
>Shouldn't the above setting prevent conflict with cdsd?
>
>We do run 443 and 434 to resimulate old designs on occasion.
>---
>Erik
>
--