You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found #1663 and while it is closed and seems resolved, the fundamental problem lives on.
In our experience there's a problem with resolving symlinks with pm2, take our example when using DeployHQ (I guess it applies to any deployment service that uses an atomic or zero-downtime deployment based on symlinks) to deploy a Next.js app (but any type of app will have the same problem) that is restarted with pm2.
Assume our deployment path is /var/www/example.com, and zero-downtime option is enabled. This means that the directory structure is like this:
$ ls -l /var/www/example.com
lrwxrwxrwx 1 next next 25 Jan 17 13:24 current -> ./releases/20250117122009
drwxr-xr-x 4 next next 4096 Jan 17 13:24 releases
drwxr-xr-x 2 next next 4096 Jan 15 18:23 shared
Now I navigate to the "current" path: cd /var/www/example.com/current
And run : pm2 start npm --name nextjs-app -- run start
Assume that the app is running correctly, I would run pm2 save to dump the state and allow pm2 startup to start the app on boot.
If I run pm2 show nextjs-app here's a truncated result:
At next deployment, when the app is restarted (an SSH command with pm2 restart is issued) the app will be restarted in the old directory, meaning the new version is not used. Furthermore, after a number of deployments (specifically one more that the Atomic Retention value, in our case it's 2) the app will not start because the deployment service has deleted the original release when the app has been started.
Our workaround is to edit the dump file, setting pm_cwd to /var/www/example.com/current, and then run pm2 kill and pm2 resurrect.
$ pm2 -v
5.4.2
The text was updated successfully, but these errors were encountered:
I found #1663 and while it is closed and seems resolved, the fundamental problem lives on.
In our experience there's a problem with resolving symlinks with pm2, take our example when using DeployHQ (I guess it applies to any deployment service that uses an atomic or zero-downtime deployment based on symlinks) to deploy a Next.js app (but any type of app will have the same problem) that is restarted with pm2.
Assume our deployment path is
/var/www/example.com
, and zero-downtime option is enabled. This means that the directory structure is like this:Now I navigate to the "current" path:
cd /var/www/example.com/current
And run :
pm2 start npm --name nextjs-app -- run start
Assume that the app is running correctly, I would run
pm2 save
to dump the state and allowpm2 startup
to start the app on boot.If I run
pm2 show nextjs-app
here's a truncated result:Notice how the
exec cwd
is not the current symlink directory, but it has been resolved to the release subdirectory.If I inspect the file
~/.pm2/dump.pm2
, I find the problem:At next deployment, when the app is restarted (an SSH command with
pm2 restart
is issued) the app will be restarted in the old directory, meaning the new version is not used. Furthermore, after a number of deployments (specifically one more that the Atomic Retention value, in our case it's 2) the app will not start because the deployment service has deleted the original release when the app has been started.Our workaround is to edit the dump file, setting
pm_cwd
to/var/www/example.com/current
, and then runpm2 kill
andpm2 resurrect
.The text was updated successfully, but these errors were encountered: