Cloud Zoo May Not Return License After an Update

Zoo
1

A curious thing happened today as a colleague and I were testing Cloud Zoo team license sharing for the first time today.

Symptoms

Cloud Zoo would not release the license from colleague’s PC, even after we closed rhino.

This began the very first time we attempted close rhino/release the license. At that time we encountered and dismissed a rhino update request. We did not realize it then, but dismissing this dialogue might have been the direct or indirect cause of the issue.

Ineffective Workarounds

  • We did perform the rhino update
  • We opened the firewall for rhino
  • We disconnected the computer from the network for a few minutes (we did not wait the full >10 minutes to see if the license would release)

None of these actions released the license or fixed the issue.

Workarounds

  • Rhino’s Logout command could release the license
  • Removing and reinstalling the license in Cloud Zoo could release the license

These fixes would release the license only temporarily; as soon as we once again checked out the license on the colleague’s computer, it would again remain captured after rhino closed down.

Apparent Cause: “Update Rhino” Zombie process

We eventually attempted a reboot, whereupon we discovered a hidden process called “Update Rhino”, when it preempted our attempt to reboot windows.

  • It had no associated window or dialogue / may have been a “zombie” process
  • Killing it released the rhino license immediately
  • If we had forced a reboot, the issue would likely have been resolved.

It is not clear what caused the process to become detached, however it appears that even in that state the process could preempt the release of rhino’s license on ordinary exit.

This may be behavior intended to prevent updates of unlicensed installations, possibly in concert with an unintended unresponsive state in the “Update Rhino” process.

Replication Ideas / Related issues

  • Simulate a rhino update event; perhaps merely dismissing the update request is enough to trigger this issue.
  • Mock up an unresponsive “Update Rhino” process; this may preempt the license check-in process.

This may be a cause of several issues like this one. It’s transient and the root cause is subtle enough that it may not always be noted.

2

@aj1 - can you help with this?

3

A related issue happened recently:

User closed rhino, but forgot to dismiss the update request.

  • Rhino continued to hold the license
  • Use believed license was released, did not detect update dialog until reboot attempt
  • Caused 10 minutes downtime and an IT triage call

Workaround: I’ve asked users to apply updates immediately - arguably the correct procedure, but not something I can enforce.

A couple solutions:

  1. Release license when main rhino windows close
    • Allow updates if a cloud zoo license exists (regardless of availability)
  2. Allow the option to force updates

I think solution 1 is reasonable and ideal; it lets teams update without risk of contention, but does not enable unlicensed usage of rhino proper. It also solves the case of the “phantom” update dialog. However, it could be complex/risky to implement; it requires a modified license release mechanism.

1 Like
5

Hello Max,
I completely agree with you, have exactly the same experience in our company.

Another helpful thing would be an option to allow users to check current usage. Users would be able to see who’s using the licence and ask them to turn Rhino off without having to rely on admin to do it for them.

Jonas