How can I start wine application as a headless service?

[widewing]

I want to start a foobar2000 instance with DLNA service with wine. I can install it with regular docker run method and with RDP, then I want to start foobar2000 before establishing RDP connection. I put the wine command as the command part, but it shows error:

0034:err:menubuilder:init_xdg error looking up the desktop directory
00c4:err:explorer:initialize_display_settings Failed to query current display settings for L"\\\\.\\DISPLAY1".
0024:fixme:msvcrt:_set_abort_behavior _WRITE_CALL_REPORTFAULT unhandled
0024:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0024:err:winediag:nodrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.

How can I start wine application as a headless service?

[Loader23]

Same here. We need some kind of autologin. If the wineuser would auto login, it could startup applications you can configure inside startup settings.

So, how to we achieve auto login?

[scottyhardy]

Hi @widewing, your application looks to be failing as it can’t find an X server. Try using xvfb-run before your command to run with a virtual X server.

[scottyhardy]

@Loader23 adding applications to start up with auto-login is very Windows-ish and generally not how Linux works or is used. If you could give some more details on what you’re trying to achieve then I may be able to give some suggestions on how it can be done.

[jmdelahanty]

Hello everyone! I'm having a similar problem trying to run a headless container. I've tried using xvfb-run before my commands and I can't seem to get it working properly.

EDIT:

It appears that the ports I'm trying to use for the DISPLAY parameter are being held used maybe even after the container is killed. Simply changing the port number that I was using solved the problem! Though not very sustainably... any idea on how to track down rogue X-servers that are keeping ports busy?

---

Here's my Dockerfile:

# docker-wine is a compatability layer between Windows and Linux.  Allows you to run Windows programs on Linux machines.
# NOTE: Do NOT use latest docker-wine repo, it will fail to use Visual C++ correctly for some reason...
FROM scottyhardy/docker-wine:stable-5.0.2-nordp

# All credit for this Dockerfile and associated ripping tools goes to Chris Roat, a software engineer at Stanford in the Deisseroth Lab
# His work has been adapted for use in the Tye Lab at the Salk Institute by Jeremy Delahanty.
# If someone is using the Tye Lab's version, they can contact Jeremy at the email below.
LABEL maintainer="Jeremy Delahanty <jdelahanty@salk.edu>"

# This adds about 1.6 GB to the image size.
# The entrypoint wrapper runs the wine setup as wineuser. This is required as it otherwise installs Wine as root causing permission problems later
# The xvfb-run wrapper redirects all displays to a virtual (unseen) display. Wine expects a display to be available.
# Winetricks
# Install visual studio C++ 2015
# This all needs to be run on the same line for some reason, otherwise it crashes
RUN /usr/bin/entrypoint xvfb-run winetricks -q vcrun2015

# Create path for conda and add it to the container's path
ENV PATH /opt/conda/bin:$PATH

# Install conda by running webget (wget) then rename download to miniconda.sh and place in home directory
# Run the miniconda installation script in the path /opt/conda
# Once installed, remove the miniconda.sh install script
# conda clean removes cached installation files: -a=all, -f=force presumably, -y=yes to all prompts
# Create soft link to conda profile.d and conda.sh
# Echo the conda shell script into bashrc so it starts when container is created
# Echo conda activate base into the bashrc so you're in base environment at start
RUN wget --quiet https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda.sh \
    && /bin/bash ~/miniconda.sh -b -p /opt/conda \
    && rm ~/miniconda.sh \
    && /opt/conda/bin/conda clean -a -f -y \
    && ln -s /opt/conda/etc/profile.d/conda.sh /etc/profile.d/conda.sh \
    && echo ". /opt/conda/etc/profile.d/conda.sh" >> ~/.bashrc \
    && echo "conda activate base" >> ~/.bashrc

# Environment is ~700 MB
COPY environment.yml .
RUN conda env update --quiet --name base --file environment.yml \
    && conda clean --all -f -y \
    && rm environment.yml

# The Tye lab does not have data collected from Prairie View 5.4, but v5.4 has
# been maintained here in case other groups need it.
COPY ["prairie_view", "/apps/prairie_view/"]

# Copy code last to avoid busting the cache.
COPY *.py /apps/
COPY runscript.sh /apps/runscript.sh

Here's how I build the container in a shell script:

#!/bin/bash

# Determine the day's date that the ripper is being run
d=$(date "+%Y%m%d")

# Create filename for the log file
log_identifier="$1-$d"

log_filename="$log_identifier".log

# Write information from python script to log file
# Order of variables (from beyblade.py):
# 1. Animal name used for container name
# 2. Full path for raw data
# 3. Truncated path for mounting data directory in container
# 4. Version of ripper to use
# 5. Total number of images to be converted
echo $1 >> logs/$log_filename
echo $2 >> logs/$log_filename
echo $3 >> logs/$log_filename
echo $4 >> logs/$log_filename
echo $5 >> logs/$log_filename


sudo docker run \
       --rm \
       --volume=$2:/data \
       --volume=/snl/scratch25/snlkt-2p/:/tmp \
       --volume=/snlkt/data/bruker_pipeline/logs:/logs \
       --env=USER_NAME=${USER} \
       --env=USER_UID=$(id -u ${USER}) \
       --env=USER_GID=$(id -g ${USER}) \
       --env=USER_HOME=${HOME} \
       --workdir=/home/${USER} \
       --env=USE_XVFB=yes \
       --env=XVFB_SERVER=:95 \
       --env=XVFB_SCREEN=0 \
       --env=XVFB_RESOLUTION=320x240x8 \
       --env=DISPLAY=:95 \
       --env=TZ=America/Los_Angeles \
       --cpus 2 \
       --shm-size=1g \
       --name=$1 \
       test:test2 \
       /apps/runscript.sh $3 $4 $log_filename

And here's the script that's executed once the container is started (runscript.sh):

#!/bin/bash

# The container executable.  This script takes no arguments, and just performs 
# minimal environment setup prior to running main script.

set -e

# USE_XVFB means xvfb is already running.  If it is unset, xvfb-run should wrap commands.
[[ -z "${USE_XVFB}" ]] && CMDPREFIX=xvfb-run

TEMPDIR="$(mktemp -d)"
export WINEPREFIX="${TEMPDIR}/.wine"
export WINEARCH="win64"

cp -r /home/wineuser/.wine "${WINEPREFIX}"

# echo
# echo "Executing rip. One err and four fixme statements are OK."
# echo
${CMDPREFIX} /usr/bin/python3 /apps/rip.py --directory $1 --ripper_version $2 --log_file $3

Most of this appears to run okay, but when it gets to the step where it tries to run the wine command for the windows application this is running, I get this error message:

000d:err:menubuilder:init_xdg error looking up the desktop directory
0028:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0028:err:winediag:nodrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.

I'm wondering if it's because I'm trying to have this not run in interactive mode that it's giving me a problem, but there are likely other problems here that I'm missing.

This is primarily all from this repository I'm trying to adapt for my lab. I'm trying to make it so users have very little to do for this step of the conversion process because not everyone is very comfortable with running things from the command line.

Any advice fellow Wine users?