Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 2

License server won't start if daemon name is in the path to lmgrd and daemon - error Status 32

Has anybody else seen this issue.  I have seen it several times over the years with several versions of FlexNet.

My last test was and it was still there.  I found a similar report on this community from 2008 and on an Intel site in 2012.

When I put everything in the following folder the license server starts.  Note the last folder NAME is NOT the vendor daemon name.  lmgrd.exe, lmtools.exe, lmutil.exe, FOO.exe (daemon) and the license file all in the same folder.  The daemon (FOO.EXE), lmgrd.exe and other utilities are all using flexnet 11.19.0.

C:\test\Flexnet\Flexnet_FOO_Daemon\FOO\TEST  ->   SERVER STARTS

However, if I use the following path where the vendor daemon name (FOO) is the LAST folder in the path then there’s an error:  Server Start Failed The Server May already be running!!

I made sure no FOO service was running using  lmtools and Windows services manager before attempting the start.

C:\test\Flexnet\Flexnet_FOO_Daemon\FOO  ->   SERVER FAILS TO START

IF it creates a debug log which it does with some FlexNet versions then the error is usually:

EXITING DUE TO SIGNAL 32 Exit reason 9
17:20:07 (lmgrd) FOO exited with status 32 (Exited because another server was running)

We instruct customers not to use the daemon name in the path containing the daemon, but when they miss that note they waste a lot of time finding it especially if no debug log is created. 

0 Kudos
(2) Replies
Level 6 Flexeran
Level 6 Flexeran

Hi Mike,
Can you please raise a support ticket for this issue along with steps to replicate and screenshots of the issue so that I can look into it?


0 Kudos

Hi Yashwanth,

I just retested with and 11.19.4 and they both worked as expected.

There was an error in my test.  I had selected lmtools.exe instead of lmgrd.exe on service config which explains why a debug log was not created.  If there was a path issue with the daemon name in past versions then it seems to be fixed.   Sorry for the false alarm.  You can remove this thread.


0 Kudos