Created On: 08 November 2011
Problem:
The ‘Statistics’ page in the License Administration Services screen for the Development License System shows more running users than the number of users displayed when the ‘lmfgetpv w’ command is run.
A customer had an issue where the number of developers able to use the Server Express development tool didn't match the number of users they were licensed for. To test, they made certain there was no one using a development/compiler license. They first ran ‘./lmfgetpv w’ from the /opt/microfocus/mflmf directory. It did not show any users currently using a license. But when they went into the License Administration Services (by using either the mflicense or mflmadm commands), then pressed the F6 function key twice to get to the 'Statistics Screen', it showed Licensed Users 16 and Running Users 2. Their developers had previously been denied a license even though they believed that at the time there should have still been some licenses available, and this confirmed it. It appeared that there must have been some rogue processes that probably had not been fully terminated and the licenses had not been released. But they were unable to identify any PID’s from the process list that would be consuming a license. Obviously a machine reboot would clear all processes. But of course that’s not always possible, as was the case in this instance. The first and most obvious option was to stop the License Manager and restart it. But, they were concerned that the License Manager might not restart until the processes had been cleared. This would have left them without being able to access any development licenses at all.
A customer had an issue where the number of developers able to use the Server Express development tool didn't match the number of users they were licensed for. To test, they made certain there was no one using a development/compiler license. They first ran ‘./lmfgetpv w’ from the /opt/microfocus/mflmf directory. It did not show any users currently using a license. But when they went into the License Administration Services (by using either the mflicense or mflmadm commands), then pressed the F6 function key twice to get to the 'Statistics Screen', it showed Licensed Users 16 and Running Users 2. Their developers had previously been denied a license even though they believed that at the time there should have still been some licenses available, and this confirmed it. It appeared that there must have been some rogue processes that probably had not been fully terminated and the licenses had not been released. But they were unable to identify any PID’s from the process list that would be consuming a license. Obviously a machine reboot would clear all processes. But of course that’s not always possible, as was the case in this instance. The first and most obvious option was to stop the License Manager and restart it. But, they were concerned that the License Manager might not restart until the processes had been cleared. This would have left them without being able to access any development licenses at all.
Resolution:
What we got them to do was to stop the License Manager (must be in the directory where the License Management Facility is installed – the default is /opt/microfocus/mflmf – and must have root privileges):
./lmfgetpv k
We then, got them to try and restart the license manager:
sh mflmman
(also from the ‘mflmf’ directory)
However, when attempting to restart, it said there were still unfinished previous processes (as the customer thought might happen).
So we then got them to try the same command with the ‘force’ option:
sh mflmman FORCE
This cleared the outstanding processes and then started the License Manager, and all licenses were then available.
Footnote:
The context of this article is that their concern was that if they stopped the License Manager they might not be able to restart it. This was a reasonable view to take and they were correct to not stop the License Manager without consulting Micro Focus, given they could not schedule a system reboot.
However, stopping the License Manager should not be a problem, because one of two things should happen:
1) If the License Manager starts when using the ‘mflmman’ command, and it does not come up with an error, then it means it has NOT recognized the rogue processes – and therefore the License Manager will be running ok. The down side of this is that the full complement of licenses will not be available (i.e. the rogue processes will still be consuming a license). If this happens then the only course of action is to reboot – but at least the development system can be used until that can be scheduled (eg in their case they still had 14 of 16 licenses available).
2) If, when restarting the License Manager there is an error stating it can’t start because not all previous processes consuming a license have been terminated, then the ‘FORCE’ option will resolve the issue by first terminating the processes and then starting the License Manager. In this instance all licenses will be available and there would be no need to reboot the machine to clear the processes.
Because it’s almost impossible to determine what might cause the rogue processes, you can’t predict which of these two possibilities might happen when attempting to restart the License Manager.
./lmfgetpv k
We then, got them to try and restart the license manager:
sh mflmman
(also from the ‘mflmf’ directory)
However, when attempting to restart, it said there were still unfinished previous processes (as the customer thought might happen).
So we then got them to try the same command with the ‘force’ option:
sh mflmman FORCE
This cleared the outstanding processes and then started the License Manager, and all licenses were then available.
Footnote:
The context of this article is that their concern was that if they stopped the License Manager they might not be able to restart it. This was a reasonable view to take and they were correct to not stop the License Manager without consulting Micro Focus, given they could not schedule a system reboot.
However, stopping the License Manager should not be a problem, because one of two things should happen:
1) If the License Manager starts when using the ‘mflmman’ command, and it does not come up with an error, then it means it has NOT recognized the rogue processes – and therefore the License Manager will be running ok. The down side of this is that the full complement of licenses will not be available (i.e. the rogue processes will still be consuming a license). If this happens then the only course of action is to reboot – but at least the development system can be used until that can be scheduled (eg in their case they still had 14 of 16 licenses available).
2) If, when restarting the License Manager there is an error stating it can’t start because not all previous processes consuming a license have been terminated, then the ‘FORCE’ option will resolve the issue by first terminating the processes and then starting the License Manager. In this instance all licenses will be available and there would be no need to reboot the machine to clear the processes.
Because it’s almost impossible to determine what might cause the rogue processes, you can’t predict which of these two possibilities might happen when attempting to restart the License Manager.
Old KB# 35186
