Terminal just says "[0K"

[M1noa]

What's happening? Concisely describe what's going wrong.

Logs

[0K
[0K

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

just setup the egg for pterodactyl panel

Runtime I'm running Muse:

• [ ] Directly from the cloned repository
• [ / ] Inside a Docker container
• [ pterodactyl ] Something else (please elaborate)

Versions

• Muse: 2.10.0
• Docker (if applicable): 27.3.1,
• OS: Ubuntu
• Node.js: (if running outside the Docker container) 20
• ffmpeg: (if running outside the Docker container, 4.1 or later is required):

[bonn2]

I am also seeing this problem in my setup on a Synology Nas via Portainer

[xiolec]

If you launch the docker container through ssh you'll see that the error is coming from not being able to create a sqllite db. Looks like the working directory is set to /usr/app while pterodactyl uses /home/container

/usr/app is also read only

[redthirten]

Was this fixed in v2.10.0 by any chance?

@xiolec Building off what you said (thanks for that find btw!), I noticed the db.sqlite's path gets set by calling createDatabasePath. This gets called here with the path of DATA_DIR, which is set to be:

path.resolve(process.env.DATA_DIR ? process.env.DATA_DIR : './data');

Which I think is set to be the container's DATA_DIR env. var. if present, or ./data if not present?

I noticed my v2.9.4 working server on Pterodactyl placed db.sqlite in /home/container/data/. I wonder if manually setting DATA_DIR could fix this issue for the latest version? I'll do some testing tomorrow and report back if I find anything.

[IrGaaT]

Was this fixed in v2.10.0 by any chance?

@xiolec Building off what you said (thanks for that find btw!), I noticed the db.sqlite's path gets set by calling createDatabasePath. This gets called here with the path of DATA_DIR, which is set to be:

path.resolve(process.env.DATA_DIR ? process.env.DATA_DIR : './data');

Which I think is set to be the container's DATA_DIR env. var. if present, or ./data if not present?

I noticed my v2.9.4 working server on Pterodactyl placed db.sqlite in /home/container/data/. I wonder if manually setting DATA_DIR could fix this issue for the latest version? I'll do some testing tomorrow and report back if I find anything.

Brother, can you please share your working pterodactyl egg because i can't get any version to work.

[redthirten]

@IrGaaT Once this (https://github.com/pelican-eggs/chatbots/pull/14) gets pulled you can grab it and effectively have what I have. However, I'm currently trying to ensure it works for the latest version of Muse first.

[redthirten]

Update: I just tried running the latest version on Pterodactyl, and here's what it prints right before it clears the console and gets stuck on [0k:

:/home/container$ yarn install && yarn start
yarn install v1.22.22
[1/5] Validating package.json...
[2/5] Resolving packages...
warning Resolution field "@types/[email protected]" is incompatible with requested version "@types/ws@^8.5.10"
success Already up-to-date.
$ patch-package
patch-package 8.0.0
Applying patches...
No patch files found
Done in 1.58s.
yarn run v1.22.22
$ npm run env:set-database-url -- tsx src/scripts/migrate-and-start.ts
> [email protected] env:set-database-url
> tsx src/scripts/run-with-database-url.ts tsx src/scripts/migrate-and-start.ts
(node:69) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("file%3A///home/container/node_modules/tsx/dist/loader.js", pathToFileURL("./"));'
(Use `node --trace-warnings ...` to show where the warning was created)
(node:99) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("file%3A///home/container/node_modules/tsx/dist/loader.js", pathToFileURL("./"));'
(Use `node --trace-warnings ...` to show where the warning was created)

I also tried setting DATABASE_URL=./data in .env, but it didn't change anything.

I would like to note that the latest image runs fine for me within Portainer, so this issue seems to be Pterodactyl-specific; but I unfortunately don't know where to start to fix this.

[marklai1998]

I'm facing this problem while trying to deploy muse with my Synology NAS + Container Manager It log a bunch of [0K and never start

I tried ssh into it and run the docker command directly and it runs perfectly fine, with the same mount and env And it back to [0K when I restart it with the UI

I speculate it's something to do with the shell and the startup screen(the fancy loading line that keep refreshing)

[OstojaOfficial]

Are there any updates on this issue?

[OstojaOfficial]

I have identified the problem with Pterodactyl, ora package used for spinner is causing this issue. After commenting out every instance where spinner is used it solves the issues.

[IrGaaT]

I have identified the problem with Pterodactyl, ora package used for spinner is causing this issue. After commenting out every instance where spinner is used it solves the issues.

Can you share your build and install script please? Thank you in advance.

[redthirten]

I know it's ultimately up to the Muse maintainers, but it's in my opinion that this ora package should be removed. I would understand it's use in an application that frequently has user-interaction in the console, but it's not necessary for a server application that is run in a headless Docker environment more often than not. It's pretty, but if it breaks in environments with atypical terminals it's not worth it.

[hazardous774]

try passing a CI=true variable to the startup of the container.

[hazardous774]

Since muse uses ora 8, it respects auto disabling spinners when in a headless environment, forcing ci will trick it into thinking its a headless session, no spinners no break, and the container will spin up properly. The egg can be modified to have a startup env var for ci=true to assist end users

On Jun 22, 2025, at 15:15, David Wolfe @.***> wrote:

 [https://avatars.githubusercontent.com/u/4533989?s=20&v=4]redthirten left a comment (museofficial/muse#1160)https://github.com/museofficial/muse/issues/1160#issuecomment-2994358033

try passing a CI=true variable to the startup of the container.

@hazardous774https://github.com/hazardous774 What does this do?

— Reply to this email directly, view it on GitHubhttps://github.com/museofficial/muse/issues/1160#issuecomment-2994358033, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHCYJVOML2OVVV46TUNNJ533E3XFHAVCNFSM6AAAAABTJCYNU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJUGM2TQMBTGM. You are receiving this because you were mentioned.Message ID: @.***>

[redthirten]

try passing a CI=true variable to the startup of the container.

@hazardous774 Oh my goodness, this works! Great find! ~~Now all we need is #1256 to be merged, because I don't think the latest release works at the moment.~~ Edit: I was wrong. Current release works fine after properly running yarn install --prod.

@M1noa I'll update the Egg soon™ with this fix, at which point you can probably close this issue as it is somewhat unrelated to the development of Muse (although, some extra documentation on their part about this env var and this issue would be appreciated).

[hazardous774]

glad to help, big fan of ur egg contributions, glad i could provide helpful insight.

[redthirten]

@hazardous774 Thanks! ♥ Fix has been committed to pelican-eggs/chatbots#14 and is now just awaiting approval and merger.