e27edfa5-ed43-4bf6-a40f-6a2089373f19

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.

Hello, Looks like this is no longer a problem?

no, seems like still occuring

can you link directly to the deployment?

https://railway.com/project/e27edfa5-ed43-4bf6-a40f-6a2089373f19/service/194ddc6b-975a-4e95-a956-319f3f9766d3?environmentId=056acaf0-c075-492c-996e-c8f30b870815

its active? im not quite sure i see the problem

the problem is its sending out crashed emails even though the deployment is active

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

likely incorrect start command

can you share your Dockerfile please?

```javascript

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 PRIVATEFTPWEBHOOKURL ARG PRIVATEFTPWEBHOOKSECRET
ARG PRIVATEFTPSERVERPORT ARG PRIVATEFTPMAXFILESIZEIN_MB

EXPOSE $PRIVATEFTPSERVER_PORT

Use the entrypoint script to generate SSH host keys and start the server

CMD ["pnpm", "--filter", "@org/ftp-server", "start"]```

i dont see anything wrong with it

hmm now that i think about it

would nodemon play a role?

does the start command use nodemon?

yes

no it doesnt, no need to worry there

if it helps, this only started occuring whenever a volume is attached

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"]

just to clarify, how did this extra step helped?

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)

The "Stopping container" is logged twice when a volume is attached.

and it's status is flagged as crashed right before being removed.

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