What does cdsMsgServer do exactly and is there an easy way to kill it after exiting cadence?

Hello,

Does anybody know what the function is of "cdsMsgServer" daemon? I've
been searching in source link but couldn't find any usefull
information on this (certainly not "446" related). I ask because we
use cadence in a non-gui mode in our makefile driven designflow in
which this cdsMsgServer daemon is bothering us (it keeps files open).
I know it will automatically exit after a certain period but I would
like to be able to end the application by hand (in a gracefull manner
that is :>))

Any help/suggestion is welcome!

Rgds,

Jan Hovius

 

Hi Jan,

Just realised that I never responded to this (and I meant to).

Anyway, cdsMsgServer is part of MPS (Message Passing Subsystem, sometimes known
as Multi-Process SKILL), together with cdsNameServer.

cdsNameServer is a place where services can advertise, and it means that
processes within a session can advertise how they can be communicated with. This
then allows SKILL remote procedure calls between sessions, which is a protocol
used for communication between Cadence tools. For example, between DFII and the
library manager or library browser, between DFII and the hierarchy editor,
between ADE and spectre.

cdsMsgServer is a bulletin board. It is used for messages to be sent by one
process in the session, and retrieved later by another process in the session.
Useful for situations where a direct connection is not needed, but something
needs to check to see if some information has been provided yet.

Neither of these services are available for end-user use. They are used by
various tools within DFII (and other tools as well).

cdsMsgServer and cdsNameServer are started as needed, and will continue until
they have not been used for some time (I think it is 10 hours of idle time, if
memory serves me correctly). There is only one cdsMsgServer and cdsNameServer
per host, and so they will usually persist after a session has completed.

Why do you want them to end? What files would it keep open (I don't think
they open any files)?

Andrew.

 

I think I know what the OP is referring to, and I see the same behavior: if I
have a project open, then close the project and try to delete or rename
certain project files and/or folders, the OS bitches that the files cannot be
manipulated because some process still has them open.

I see this particularly when switching back and forth between major Cadence
versions and related projects. Killing the nameserver and messageserver
processes allows switching versions or manipulating these same files without
any other headaches...

/daytripper

 

I'm sorry, but I don't think cdsNameServer and cdsMsgServer have anything to
do with this. I change versions extremely frequently (since I'm in customer
support, it is many times per day), and _never_ see problems like this.

Killing cdsNameServer/cdsMsgServer can be problematic if there are processes
running which are still using their services - it can cause those other
still-running processes (things like cdsdoc for example) to then get stuck, or
fail to communicate with each other.

So, some details of what these files are would be useful before making such a
statement...

Andrew.

 

I have to agree with Andrew. I currently have 4.4.5, 4.4.6, 5.0.0,
5.0.32, 5.0.33ISR, 5.0.33USR2 (before, during, and after the cdsVia
fiasco), 5.0.33USR3, 5.0.41, 5.1.41ISR, 5.1.41USR1, 5.2.51, and 5.2.51OA
installed and/or built on my workstation. They all play together,
occasionally at the same time, without ever needing to kill anything.

Of course, I have the latest versions available installed, or things
that are not yet available, so maybe your problem is you are running
code that still has some of the bugs that have been fixed since the
initial release. I seem to recall there being a bug in the early builds
of 5.0.32 that might be what you are seeing.

 

Sorry for this late reply. I wasn't aware there finally was some
response on this question. Unfortunately I can't recall what the exact
reason was for this posting (sorry Andrew can't give you a
name/example) but it indeed was a locking issue after exiting your
cadence environment. The problem surfaced in our attempt to automate
our synchronicity based makefile flow in which we directly have to
access files in the cadence design database.
Andrew, I have to consult my collegue again (he ran into this problem)
for the details (in the meantime he already found a workaround for
it).


Rgds,

Jan.

 

Hi Jan,

Apologies again for the lateness of my original reply - I got a bit backlogged
in processing things (they day job got in the way ;-> )

One situation I've seen where daemons started by DFII causign trouble
occasionally is with LSF. From my understanding LSF doesn't see a job as
finished if it still has child processes running (i.e. processes in the same
process group). Not sure if that's the case here, but I know in the past some
customers have had to do various things with some daemons (like explicitly
starting them on a machine in a compute farm) to get around this.

There may be ways around it in LSF too - but I'm not really that familiar with
LSF.

Andrew.

 

Andrew,

The "filelocking" problem occured in our make-flow. At a certain part
in this flow we (automatically) start cadence in a temporary area in
"no gui" mode, for example to extract the latest gds2 from a block if
the makefile decided that already existing one is outdated compared to
the cadence source). After this cadence job has finished the make
process continues which also implies removing the temporary cadence
workarea. This however fails because the cdsMsgServer is still running
(and app. locking some database files in it, even though cadence has
already finished).

This was the reason for me asking the original question..... hope this
explains it a bit more.

Rgds,

Jan.

 

Hi Jan,

By locking, do you mean Cadence locking (i.e. .cdslck files)? If so,
cdsMsgServer doesn't do that at all - so I'd be really surprised if cdsMsgServer
was the cause here. In fact I wouldn't think it was doing any sort of locking
(I'm pretty sure it doesn't).

So yes, it may (or rather will) still be running, but I don't think it can have
been the culprit for the symptoms you're describing.

Best Regards,

Andrew.

 

Andrew,

No there was no cadence locking involved in this case. As said, after
finishing the cadence job the make flow wants to remove the temporary
workspace (using unix "rm") and at this point it fails because files
are locked by a process on OS level. We found out that it appeared to
be cdsMsgServer by using the solaris8 'fuser' command

As said, it was one of my collegues who encountered this problem back
then and in the meantime he already has a workaround but it made us
wonder what the functionality of this daemon was and whether we could
control its behaviour.

Rgds,

Jan.

 

Jan,

I did some checks on a running session, using fuser, and found that the only
filesystems it seemed to be referring to (cdsMsgServer) were /tmp (which is its
working directory) and the installation of Cadence (because it has the
executable memory mapped).

Also, as soon as I exit DFII, cdsMsgServer ends (I forgot, cdsMsgServer is
one-per-session; cdsNameServer is one-per-host).

So I'm not sure what the problem was...

Regards,

Andrew.