[BUG] Cannot start fresh standalone server - syncing-server-js-standalone issues
Service Versions (please complete the following information):
Paste the output of ./server.sh version. For example:
Container Repository Tag Image Id Size
api-gateway-standalone standardnotes/api-gateway latest 2d1bcfff94ec 427MB
auth-standalone standardnotes/auth latest 46141736c362 629MB
auth-worker-standalone standardnotes/auth latest 46141736c362 629MB
cache-standalone redis 6.0-alpine 1d4d1d8ecb73 31.3MB
db-standalone mysql 5.6 da4f8ea7ee60 303MB
files-standalone standardnotes/files latest 60afc1806b0c 166MB
syncing-server-js-standalone standardnotes/syncing-server-js latest 17bd21810f66 620MB
syncing-server-js-worker-standalone standardnotes/syncing-server-js latest 17bd21810f66 620MB
Describe the bug
When running ./server.sh start from fresh install, standalone server does not complete start and show this error instead:
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "./packages/syncing-server/wait-for.sh": stat ./packages/syncing-server/wait-for.sh: no such file or directory: unknown
To Reproduce Steps to reproduce the behavior:
- Follow self-hosting instructions until
./server.sh start
Expected behavior The server should start.
Logs
svarto@xxx:~/standalone$ ./server.sh start
Starting up infrastructure
[+] Running 3/4
⠿ Container cache-standalone Running 0.0s
⠿ Container files-standalone Running 0.0s
⠿ Container db-standalone Running 0.0s
⠏ Container syncing-server-js-standalone Starting 1.9s
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "./packages/syncing-server/wait-for.sh": stat ./packages/syncing-server/wait-for.sh: no such file or directory: unknown
Your latest image may outdate because previously wait-for.sh is under ./ now it is under ./packages/<packagename/.
try do docker-compose pull to update image and then docker-compose up.
BTW, that's the reason why we all hate latest tag. My latest in not the same as your latest.
I just recommend developers to pin the tag with https://github.com/standardnotes/server 'e release tag like @standardnotes/[email protected] (maybe to avoid conflict with old tags adding a prefix v -> v1.21.1)
Some ref comments: https://github.com/standardnotes/standalone/issues/81#issuecomment-1205283517