Should `hackage-server init` be creating a lockfile?

[phlummox]

This arises using hackage-server 0.5.1, as built from the hackage-deployment-2020-05-03 tag (commit d43012169a11a0bb2229ef207e607b6c3d83b99c) on Ubuntu 18.04. I used a slight variation of the provided Dockerfile

(The exact Dockerfile used is given here.)

FROM ubuntu:18.04@sha256:0fedbd5bd9fb72089c7bbca476949e10593cebed9b1fb9edf5b79dbbacddd7d6 \
   as build

ARG GHC_VERSION=8.2.2 \
    CABAL_VERSION=3.0

RUN  \
      apt-get update  \
  &&  apt-get install -y --no-install-recommends \
          software-properties-common \
  &&  DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
        git         \
        libicu-dev  \
        libssl-dev  \
        unzip       \
        zlib1g-dev  \
  &&  apt-add-repository ppa:hvr/ghc \
  &&  apt-get update \
  &&  DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
          cabal-install-${CABAL_VERSION} \
          ghc-${GHC_VERSION}  \
  # Remove  unnecessary stuff
  &&  apt-get autoclean \
  &&  apt-get clean -y  \
  &&  apt-get --purge -y autoremove \
  &&  rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

ENV PATH /opt/ghc/bin:$PATH

RUN mkdir /build
WORKDIR /build

ARG HACKAGE_VERSION=hackage-deployment-2020-05-03

RUN \
      cabal v2-update \
  &&  git clone https://github.com/haskell/hackage-server.git . \
  &&  git checkout ${HACKAGE_VERSION} \
  &&  cabal v2-build --only-dependencies \
  &&  cabal v2-install --install-method=copy --constraint='text < 2.0'  hackage-repo-tool

ENV PATH /root/.cabal/bin:$PATH

RUN \
      hackage-repo-tool create-keys --keys keys \
  &&  cp keys/timestamp/*.private datafiles/TUF/timestamp.private \
  &&  cp keys/snapshot/*.private datafiles/TUF/snapshot.private \
  &&  hackage-repo-tool create-root --keys keys -o datafiles/TUF/root.json \
  &&  hackage-repo-tool create-mirrors --keys keys -o datafiles/TUF/mirrors.json \
  &&  cabal v2-build \
  &&  cabal v2-install --install-method=copy

###
# server

FROM ubuntu:18.04@sha256:0fedbd5bd9fb72089c7bbca476949e10593cebed9b1fb9edf5b79dbbacddd7d6

SHELL ["/bin/bash", "-c"]

ARG CABAL_DIR=/root/.cabal
ENV PATH ${CABAL_DIR}/bin:$PATH
COPY --from=build ${CABAL_DIR}/bin ${CABAL_DIR}/bin

RUN  \
      apt-get update  \
  &&  DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
        ca-certificates   \
        curl              \
        libicu60          \
        libssl1.1         \
        netbase           \
        zlib1g            \
  # Remove  unnecessary stuff
  &&  apt-get autoclean \
  &&  apt-get clean -y  \
  &&  apt-get --purge -y autoremove \
  &&  rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*#

# setup server runtime environment

RUN mkdir /runtime
WORKDIR /runtime

COPY --from=build /build/datafiles /runtime/datafiles

RUN \
      hackage-server init --static-dir=datafiles

Running hackage-server init command results in the following output:

$ hackage-server init --static-dir=datafiles
hackage-server: Creating initial state...
finalising data for feature users
finalising data for feature core
finalising data for feature security
hackage-server: Using default administrator account (user admin, passwd admin)
hackage-server: Done

On my system at least, this seems to reliably create the file state/db/Tags/Alias/open.lock - should this be happening? Usually, I'd expect the existence of a lockfile to indicate there's a running instance of hackage-server, which obviously isn't the case here.

The existence of the lockfile seems to sporadically result in errors when hackage-server run is executed. Sometimes (but not always), running hackage-server run --static-dir=datafiles --base-uri=http://localhost:8080/ will result in an error like the following:

state/db/Tags/Alias/open.lock: Locked by 1: resource busy

It seems like hackage-server init shouldn't be creating a lockfile, but perhaps this is intended behaviour. If it is, perhaps it would be worth documenting what the purpose of the lockfile is.

[gbaz]

It shouldn't be creating a lockfile, no. Those files are afaik created and managed by the acid-state library (https://github.com/acid-state/acid-state/search?q=open.lock) and perhaps the snapshot you're using is built against an older version of that lib? I haven't seen this reported otherwise so no particular guesses. I will say we haven't been tagging deployments lately, but a much newer commit is in production as central-server now, so it couldn't hurt to update.

[gbaz]

(or rather, it might create the lockfile while setting up the init, but that file should be removed afterwards I believe)

[phlummox]

Hi @gbaz, thanks for that. I'll try with a current checkout of the repo when I get a chance, and let you know if I observe the same behaviour. Cheers!