Headless Mode Isn't Really Headless

Unity Engine
,
1

I’m trying to use the Hub in a docker container. Here is the image Dockerfile:

FROM ubuntu:16.04

WORKDIR /tmp
COPY UnityHub.AppImage .
RUN chmod +x UnityHub.AppImage
RUN apt-get -qq update && apt-get -qq install -y --no-install-recommends apt-utils && apt-get -qq install -y \
    fuse \
    xdg-utils \
    desktop-file-utils \
    zenity \
    xvfb \
    && apt-get clean

I run the image like this:

docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse unityhubdocker:1.0 bash

(the SYS_ADMIN and fuse device are so the AppImage works)

If I try to start the Hub:

/tmp/UnityHub.AppImage -- --headless help

This is the output:

Failed to connect to Mir: Failed to connect to server socket: No such file or directory
Unable to init server: Could not connect: Connection refused

(zenity:243): Gtk-WARNING **: cannot open display:

So it can’t connect to the display, which I was hoping I wouldn’t need. (since there is no display and this is headless mode)

This can be worked around by using xvbf but I wish I didn’t have to.

So now the command is this:

xvfb-run -a --error-file /var/log/xvfb_error.log --server-args="-screen 0 1024x768x24 +extension RANDR" /tmp/UnityHub.AppImage -- --headless help

This starts successfully - cool!

Unfortunately it just sits. Let’s see what is running in the container:

$ docker top 8ff3edbb5b73
PID                 USER                TIME                COMMAND
16472               root                0:00                bash
16757               root                0:00                {xvfb-run} /bin/sh /usr/bin/xvfb-run -a --error-file /var/log/xvfb_error.log --server-args=-screen 0 1024x768x24 +extension RANDR /tmp/UnityHub.AppImage -- --headless help
16769               root                0:00                Xvfb :99 -screen 0 1024x768x24 +extension RANDR -nolisten tcp -auth /tmp/xvfb-run.fTxaoN/Xauthority
16780               root                0:00                {AppRun} /bin/bash /tmp/.mount_UnityHYyu2ki/AppRun -- --headless help
16783               root                0:00                /tmp/UnityHub.AppImage -- --headless help
16790               root                0:00                zenity --text-info --title=Unity Hub --filename=/tmp/.mount_UnityHYyu2ki/eula.txt --ok-label=Agree --cancel-label=Disagree

It looks like we are waiting for a zenity dialog.

I would really like to agree but I don’t know how. Any tips on what I can do for now to get past this? (can I manually set a value on-disk to say I have agreed or something?)

TLDR:

  • Make headless mode not require a display.
  • Show the agree/disagree prompt in the CLI if using headless mode. (and don’t hang on UIs when in headless mode) Allow us to pipe ‘yes’ to automate the process.
8 Likes
2

Reproduced the same issue on Ubuntu 18.04 as well

3

Hi @btristan ,

I feel we haven’t been completely accurate with the term “headless”. It does indeed still use electron and probably requires a display. I don’t know when we will change that right now but I understand this can be misleading and quite unusable for your current use case. I’ll relay this to the team.

3 Likes
4

Awesome, thanks!

Any chance there is a workaround for the zenity EULA dialog? That’s the last thing that is preventing us from using it. (we can live with the virtual display workaround)

5

EULA dialogs haven’t been ported to CLI prompts yet. Frankly we haven’t made much progress beyond the first iteration for now but these are things we will implement as the feature matures. For now unfortunately there are no workarounds.

6

Hi, Some update about this?

7

@fortunacio Sorry, not yet. Not sure when we’ll address this.

8

A possible workaround: xdotool

It can be used to move a mouse cursor to a position and click buttons.

Usage:
https://stackoverflow.com/a/20665793/2669980

I haven’t tested it yet.

9

I have a workaround for the dialog boxes!

Dockerfile:

FROM ubuntu:16.04

# dependencies
RUN apt-get -qq update && apt-get -qq install -y --no-install-recommends apt-utils && apt-get -qq install -y --no-install-recommends --allow-downgrades \
# dockerfile dependencies
    ca-certificates \
    wget \
# hub dependencies
    desktop-file-utils \
    fuse \
    libasound2 \
    libgtk2.0-0 \
    libnss3 \
    xdg-utils \
    xvfb \
    zenity \
    libdbus-glib-1-2 \
    && apt-get clean

# get the Hub
ARG UNITY_DIR='/opt/unity'
ENV UNITY_HUB_PATH="${UNITY_DIR}/UnityHub.AppImage"
RUN mkdir "${UNITY_DIR}"
RUN wget --no-verbose -O "${UNITY_HUB_PATH}" 'https://public-cdn.cloud.unity3d.com/hub/prod/UnityHub.AppImage'
RUN chmod 555 "${UNITY_HUB_PATH}"

# install the Hub
ARG APPLICATIONS_DIR='/usr/local/share/applications'
ARG APPIMAGE_DESKTOP_FILE_NAME='unityhub.desktop'
ARG TMP='/tmp'
ARG INTEGRATED_DESKTOP_FILE='/usr/local/share/applications/appimagekit-unityhub.desktop'
ARG EDITORS_DIR="${UNITY_DIR}/editors"
ARG HUB_CONFIG_DIR='/root/.config/UnityHub'
RUN mkdir -p "${APPLICATIONS_DIR}"
RUN (cd "${TMP}" && "${UNITY_HUB_PATH}" --appimage-extract "${APPIMAGE_DESKTOP_FILE_NAME}")
RUN mv "${TMP}/squashfs-root/${APPIMAGE_DESKTOP_FILE_NAME}" "${INTEGRATED_DESKTOP_FILE}"
RUN chmod 755 "${INTEGRATED_DESKTOP_FILE}"
RUN mkdir -p "${EDITORS_DIR}"
RUN mkdir -p "${HUB_CONFIG_DIR}"
RUN echo "\"${EDITORS_DIR}\"" > "${HUB_CONFIG_DIR}/secondaryInstallPath.json"

Run the image:

docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse --security-opt apparmor:unconfined localhost/btristan/unitycontainerbuildimage bash

Get the editor install path:

xvfb-run -a --error-file /var/log/xvfb_error.log --server-args="-screen 0 1024x768x24 +extension RANDR" /opt/unity/UnityHub.AppImage -- --headless install-path --get | head -n 1

I still don’t know if this will work for license activation but we are getting there!

One big problem is that I can’t execute the Hub when building the image so I’ll still have to get the standalone installer. :frowning:

1 Like
10

Bad news is that I still can’t activate the license. I downloaded and installed 2019.3.0f6 and used the CLI to activate the license but it still fails, even when the hub is running. The funny thing is that a seat is allocated and a license file is generated. IDK what gives.

Looks like we will just have to wait for the Hub CLI anyways. :frowning:

11

I tried adding a wait between activation and starting the Editor. (I saw there was a delay on my personal computer between when I activated and when the Hub would let me open a project)

Unfortunately this still doesn’t work.

12

Any update on this?

13

Any updates on this issue? I’m having problems using UnityHub in docker container related to this problem.

14

Hey all,

Sorry, I don’t think this will be tackled soon. I’ll poke the team about adding an option to pre-approve the EULA if that will help.

Best,

1 Like
15

What sort of issue are you having? My dockerfile should allow you to use the Hub if needed. You would still need to execute the Editor to activate a license: https://docs.unity3d.com/Manual/CommandLineArguments.html

You don’t need the Hub to activate a license: https://issuetracker.unity3d.com/issues/cannot-activate-license-within-a-docker-container

1 Like
16

Hi btristan,

Thank you for your reply. I downloaded 2019.4.0f1 from https://discussions.unity.com/t/595006 page-2 and when I try to run the Editor, it tells me to activate the license through Unity Hub and redirects me to the download page for Unity Hub. I have also tried to used the CLI to activate Unity, but it still prompts me to use the hub to activate the license. The next thing I have done is VNC into the container and run Unity Hub, but nothing shows up while it is still running. I’m running this docker container on a mac host. I’m not sure if that is the problem. I do have access to a Windows machine if that makes any difference. From your link
https://issuetracker.unity3d.com/issues/cannot-activate-license-within-a-docker-container
Does there exist a Linux version with this fix?

I have also run your Dockerfile and ran your commands, but I get this error

xvfb-run -a --error-file /var/log/xvfb_error.log --server-args="-screen 0 1024x768x24 +extension RANDR" /opt/unity/UnityHub.AppImage -- --headless install-path --get | head -n 1
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

UPDATE: I was able to run UnityHub using a VNC. Going to work with this and see if I can run the editor after downloading Unity.

UPDATE2: Things are working now. I have to iron out some of these minor issues. Thanks btristan!

17

@btristan can you explain how https://blogs.unity3d.com/2020/06/17/scaling-kubernetes-jobs-for-unity-simulation/ is doing headless operation?

18

I’m not aware of exactly how since I’m not privy to the internals of Unity Simulation. Also, my efforts have so far been to get the Editor to run in the cloud for build automation. However, I have two guesses:

  • Unity may have created an internal build that runs on the cloud more easily.
  • They may have forwarded the host X11 context (if running on Linux) and allowed Kupernetes to access the GPU. (you can do the same sort of thing with nvidia-docker if you are using Docker) This would be the way us outsiders would have to do it.
1 Like
19

Oops, sorry, I meant to ping @AbrahamDUnity above

20

Any update on this headless issue?