Search Issue Tracker

Fixed in 2020.2

Fixed in 2019.4, 2020.1

Votes

19

Found in

2018.4

Issue ID

1193364

Regression

Yes

Cannot activate license within a docker container

Windows

-

Following this bug report in our forums (https://forum.unity.com/threads/batch-mode-license-activation-fails-in-a-docker-container.748325/), we have discovered that the reason that the license activation fails from within this docker instance is that our implementation of GetInternetReachability seems to fail within the docker container.

I didn't double-check the instance given by the customer ("matissehack/unity"), and can only assume that it represents the same thing that we would have if we had built it ourselves.

Basically, we call CoCreateInstance(CLSID_NetworkListManager, ...), and then call GetConnectivity on the returned instance. This latter call fails, which (eventually) prevents license activation.

Reference: https://stackoverflow.com/questions/17648194/how-can-i-start-my-application-when-network-connection-is-available

Note: the above description was for a bug that a client reported using Unity within a Windows docker container.
But it became an umbrella for more bugs using Unity within a Linux docker container.

  1. Response avatar

    Resolution Note (fix version 2020.2):

    The docker instance masks the machine Id (/etc/machine-id), required for building the license file.
    It is not acceptable that it be left empty.

  2. Response avatar

    Resolution Note (fix version 2020.2):

    Fixed in version 2020.2.0b9

  3. Response avatar

    Resolution Note (fix version 2020.1):

    Fixed in version 2020.1.0f1

  4. Response avatar

    Resolution Note (fix version 2019.4):

    Fixed in version 2019.4.7f1

Log in to vote on this issue

Comments (8)

  1. 061654dc607c49de1933b362a0dc9264?d=mm

    jonalbert

    Dec 14, 2020 17:46

    patientfusion.us

  2. Acdc26a6d9393f7441b80c53c4ef9596?d=mm

    Unity2-3drepo

    Jun 18, 2020 15:54

    We were using containers successfully until 2019.3. We only just upgraded to 2019.3

  3. F83ebf1eed1c11af2ff298856f0bb3f3?d=mm

    btristan

    Feb 27, 2020 22:13

    +1

    This is blocking an upgrade to Unity 2019.3 in Ubuntu containers as well.

  4. 60afcb071b465f2a813fc6fbd58cdb13?d=mm

    Sarbakan-Support

    Feb 13, 2020 13:45

    Looks like we can't upgrade to 2019.3 or 2020.1 either.
    At least this issue was reopened after being marked as "won't fix" at first.

  5. B10e5a44a37c0cda91acf4e90d555782?d=mm

    Filiecs

    Feb 11, 2020 17:26

    If this is not fixed it will prevent us from upgrading to 2019.3.

  6. 569959208a89d994f7bb8760a7ea239a?d=mm

    danielo_unity

    Feb 10, 2020 17:54

    After further investigation, this API (INetworkListManager::GetConnectivity) was found to be not working because the netprofm service ("Network List Service") is disabled within this container (matissehack/unity) or the base image, either by accident or by design.
    Re-enabling netprofm is insufficient, as it depends on another service (nlasvc), which must also be re-enabled.
    Furthermore, another critical service is also required, by licensing and perhaps elsewhere: WMI (wmiApSrv).
    I have not investigated beyond this point (license activation passes), but would speculate that there will be other issues (not a huge amount, but some).
    docker is not really used internally. We use VMs. docker support will take time and effort (and users).

  7. 557d55c66789638f06a3ed1af7ee54a1?d=mm

    Nepoxx

    Feb 06, 2020 16:29

    How is "won't fix" acceptable for this issue?

    There's no explanation as to why, nor any workarounds. There's a lot of people using this to automate their Unity builds, this is clearly not acceptable.

    I feel like you guys are actively making sure automating our builds is a pain to sell your Unity cloud build.

  8. Fde4044ec6ff0ed0039dd6cbe58f4cdb?d=mm

    fake_aki

    Nov 12, 2019 12:02

    Seems like the check is just done the wrong way around, since INetworkListManager::GetConnectivity is obviously not an authoritative source of knowledge in practice. The right way would be to attempt to connect to the service first, and to perform a general Internet connectivity check on the network interface as an additional diagnostic if it fails.

    Running Unity in a Docker container is a common pattern for building CI, so this is going to present a major blocker to updating for many people. In our case, releases up to 2019.1 are working well, but with 2019.3 betas we've started to run into trouble.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.

Livehelp

Latest issues

See all new issues