Railway•7mo ago

Container Takes Hours To Start or Sometimes Just Doesn't

I'm trying to deploy a docker container to railway and it builds with no errors from the dockerfile, but the deploy produces no logs for hours and the service is unavailable. Sometimes after waiting a few hours it'll eventually start but most of the time it just sits with no logs or info coming out of the deploy. Here's the dockerfile I'm using:

FROM haskell:9.4.7-buster

WORKDIR /opt/<service-name>

RUN apt install --no-install-recommends curl

RUN cabal update

# Add just the .cabal file to capture dependencies
COPY ./<service-name>.cabal /opt/selene/<service-name>.cabal

# Docker will cache this command as a layer, freeing us up to
# modify source code without re-installing dependencies
# (unless the .cabal file changes!)
RUN cabal new-build --only-dependencies -j4

# Add and Install Application Code
COPY . /opt/<service-name>
RUN cabal new-install exe:<service-name> -j4

CMD ["<service-name>"]

FROM haskell:9.4.7-buster

WORKDIR /opt/<service-name>

RUN apt install --no-install-recommends curl

RUN cabal update

# Add just the .cabal file to capture dependencies
COPY ./<service-name>.cabal /opt/selene/<service-name>.cabal

# Docker will cache this command as a layer, freeing us up to
# modify source code without re-installing dependencies
# (unless the .cabal file changes!)
RUN cabal new-build --only-dependencies -j4

# Add and Install Application Code
COPY . /opt/<service-name>
RUN cabal new-install exe:<service-name> -j4

CMD ["<service-name>"]

Solution:

how are you logging? are you logging unbuffered to stdout / stderr?

Jump to solution

13 Replies

Percy•7mo ago

Project ID: 60e7b407-448b-408b-84c2-c8ac25deef63

AlecOP•7mo ago

60e7b407-448b-408b-84c2-c8ac25deef63 Like most of the "deploy" logs for this service are just fully empty. Only when a new deploy doesn't happen for many hours it'll have the start logs from my app show up with a timestamp that's hours after the "deploy" time

Brody•7mo ago

please attach the Dockerfile without the needless censoring

AlecOP•7mo ago

sure I didn't think it made a difference

FROM haskell:9.4.7-buster

WORKDIR /opt/selene

RUN apt install --no-install-recommends curl

RUN cabal update

# Add just the .cabal file to capture dependencies
COPY ./selene.cabal /opt/selene/selene.cabal

# Docker will cache this command as a layer, freeing us up to
# modify source code without re-installing dependencies
# (unless the .cabal file changes!)
RUN cabal new-build --only-dependencies -j4

# Add and Install Application Code
COPY . /opt/selene
RUN cabal new-install exe:selene -j4

CMD ["selene"]

FROM haskell:9.4.7-buster

WORKDIR /opt/selene

RUN apt install --no-install-recommends curl

RUN cabal update

# Add just the .cabal file to capture dependencies
COPY ./selene.cabal /opt/selene/selene.cabal

# Docker will cache this command as a layer, freeing us up to
# modify source code without re-installing dependencies
# (unless the .cabal file changes!)
RUN cabal new-build --only-dependencies -j4

# Add and Install Application Code
COPY . /opt/selene
RUN cabal new-install exe:selene -j4

CMD ["selene"]

Brody•7mo ago

the little details matter does this dockerfile build an image and run fine locally?

AlecOP•7mo ago

Yep and in ECS and in my K8S cluster

Brody•7mo ago

zero logs what so ever for hours?

AlecOP•7mo ago

yep

Solution

Brody•7mo ago

how are you logging? are you logging unbuffered to stdout / stderr?

AlecOP•7mo ago

I believe so let me check This is the entry point code:

main :: IO ()
main = do
  withEnv $ \env -> do
    appToRun <- Scotty.scottyAppT (runM env) (app env)
    let warpSettings = setPort 3005 defaultSettings
    runM env $ do
      $logInfo "Selene start at port 3005"

    runSettings warpSettings appToRun

main :: IO ()
main = do
  withEnv $ \env -> do
    appToRun <- Scotty.scottyAppT (runM env) (app env)
    let warpSettings = setPort 3005 defaultSettings
    runM env $ do
      $logInfo "Selene start at port 3005"

    runSettings warpSettings appToRun

I'm not super familiar with the internals of the haskell io monad but I was pretty sure this logs unbuffered to stdout, doing some more research now

Brody•7mo ago

i am even less familiar

AlecOP•7mo ago

ok i think you might be right on the stdout log buffering thanks!

Brody•7mo ago

and just to be clear, your service will always stay unavailable, even once the logs do print? application failed to respond, right? if so, please check out this docs page - https://docs.railway.app/guides/fixing-common-errors

Gaming

Programming

Container Takes Hours To Start or Sometimes Just Doesn't