2 years ago
not a big deal, but whenever a redeployment happens with a service that has a volume attached, the previous deployment is marked as crashed and sends out a crashed email when shutting down.
29 Replies
We tested by removing the volume, and redeploying, not seeing any crash email/statuses. But with the volume attached, the "Stopping container" is logged twice, and the status enum shows "Crashed" for a moment before being removed.
2 years ago
Hello, Looks like this is no longer a problem?
2 years ago
can you link directly to the deployment?
2 years ago
its active? im not quite sure i see the problem
the problem is its sending out crashed emails even though the deployment is active
2 years ago
gotcha, can you share your Dockerfile please
and from our testing it seems that when taking the previous deployment offline for the latest deployment to take over, the previous deployment crashes right before it being removed
2 years ago
likely incorrect start command
2 years ago
can you share your Dockerfile please?
FROM node:20.17.0
# Set working directory
WORKDIR /apps
# Install pnpm with the correct version
RUN npm install -g pnpm@9.14.2
# Copy everything
COPY . .
# Install dependencies
RUN pnpm install --frozen-lockfile
# Define build arguments
ARG PRIVATE_FTP_WEBHOOK_URL
ARG PRIVATE_FTP_WEBHOOK_SECRET
ARG PRIVATE_FTP_SERVER_PORT
ARG PRIVATE_FTP_MAX_FILE_SIZE_IN_MB
EXPOSE $PRIVATE_FTP_SERVER_PORT
# Use the entrypoint script to generate SSH host keys and start the server
CMD ["pnpm", "--filter", "@org/ftp-server", "start"]```
2 years ago
does the start command use nodemon?
2 years ago
no it doesnt, no need to worry there
2 years ago
so you would want to build the ftp-server with tsc and then run the resulting .js file directly -
...
RUN pnpm --filter @org/ftp-server build
...
# Please replace with the actual path to the .js file, this is just a guess
ENTRYPOINT ["node", "/apps/apps/ftp-server/dist/src/index.js"]2 years ago
this is the correct start command syntax, running through pnpm is not good for production environments
We do this for our other production environment, we are not looking for advice on that. This issue is related to volumes.
We have already tested several times, and it's only occuring when a volume is attached. The container is stopped twice. (one time seemingly preemptively, isolated to having a volume attached)
2 years ago
I can't see this being related to volumes, pnpm is not passing the correct signals and thus your app is crashing when we remove the old deployment, please try my suggestion and then we can go from there