silverbulletmd / silverbullet

The knowledge tinkerer's notebook
https://silverbullet.md
MIT License
2.35k stars 169 forks source link

silverbullet silently died after some time of working with Internal Server Error. prob after new container version #772

Open skorphil opened 7 months ago

skorphil commented 7 months ago

Hi, i'm using containerized silverbullet behind caddy reverse proxy. It worked fine but recently i found out is is died. I get Internal Server Error 500 when I try to access it. I have not used it for maybe a month or so, so do not know, when exactly did it die.

Other services behind caddy working fine, also nothing is being changed on vps itself. ssh -L 3000:127.0.0.1:3000 MY_VPS returns same error, so its not a caddy issue, but SB itself. Restarting the container does not help

Any way I can investigate the problem? container logs show nothing: Screenshot 2024-03-02 at 11 01 11

My guess is watchtower update broke it idk. Info about caddy container Screenshot 2024-03-02 at 11 07 02

zefhemel commented 7 months ago

Can you try creating an empty folder and point it at that as /space and see if that does anything?

SONDLecT commented 7 months ago

Hm. I'm experiencing the same problem, I think. Internal server error out of the blue. I've tried compose pulling to make sure things are up to date, I've made sure there are no permissions issues on the space dir, I've even deleted the .silverbullet-db files to let it try to rebuild things -- no go. In the logs I'm getting a

An exception was thrown as a result of invoking function showIfEnabled error: Unregistered syscall clientStore.get
Error dispatching event plug:load to treeview.showIfEnabled: Unregistered syscall clientStore.get
Error: Unregistered syscall clientStore.get
    at wa.onMessage (file:///silverbullet.js:117:27742)
    at Worker.worker.onmessage (file:///silverbullet.js:117:27261)
    at Worker.wrappedHandler (ext:deno_web/02_event.js:1401:12)
    at innerInvokeEventListeners (ext:deno_web/02_event.js:754:7)
    at invokeEventListeners (ext:deno_web/02_event.js:801:5)
    at dispatch (ext:deno_web/02_event.js:658:9)
    at Worker.dispatchEvent (ext:deno_web/02_event.js:1043:12)
    at Worker.#pollMessages (ext:runtime/11_workers.js:212:12)
    at eventLoopTick (ext:core/01_core.js:166:7)

Creating a new empty directory and pointing that as /space in the compose file did seem to let it spin up, though adding files back into the new space directory caused the error to return

joekrill commented 7 months ago

Do you have my treeview plug installed by chance? I was getting the same error after updating to the latest edge release. When I removed that plug and restarted it worked fine. Once up-and-running, re-enabling the plug worked.

@zefhemel This is the code that seems to be causing it. But I'm not really sure why it would be doing that. My guess is that the plug is being loaded before the clientStore syscalls are registered? Is that expected behavior? Should my plug be handling this differently (or wrapping this code in a try-catch?). I saw this error at some point:

An exception was thrown as a result of invoking function showIfEnabled error: Unregistered syscall clientStore.get
dispatching event plug:load to treeview.showIfEnabled: Unregistered syscall clientStore.get

@skorphil and @SONDLecT - try deleting the _plugs/treeview.plug.js file from your space and restarting as a temporary workaround. (Once running, update your plugs and the treeview should return).

zefhemel commented 7 months ago

@joekrill the clientStore syscalls are only going to be available in the client (hence the name), the plug:load is going to be triggered on the server as well, so it would indeed fail with this error. Not sure what this happens now and not earlier. What you can do in your plug:load call is check the environment it's running in (system.getEnv()) to ensure it's the client where the event is triggered.

joekrill commented 7 months ago

@joekrill the clientStore syscalls are only going to be available in the client (hence the name), the plug:load is going to be triggered on the server as well, so it would indeed fail with this error. Not sure what this happens now and not earlier. What you can do in your plug:load call is check the environment it's running in (system.getEnv()) to ensure it's the client where the event is triggered.

OK. Yeah that's strange because that's been in there since the beginning. I just pushed an update and removed the plug:load - I'm pretty sure that's not necessary.

Interestingly, when I tried to use the Update Plugs command I get this error:

Error updating plugs: Unregistered syscall index.queryPrefix

SONDLecT commented 7 months ago

@joekrill I did indeed have treeview, that seemed to be the culprit. Deleting the .js file and reloading things seemed to fix the issue.

PatrikStenmark commented 6 months ago

Not sure if this is helpful: I just had the same issue, when upgrading from 0.7.5 to 0.7.6. For me, downgrading to 0.7.5 again solved the problem.

Doing an Update plugs on 0.7.5 and then upgrading to 0.7.6 again worked fine.

joekrill commented 6 months ago

Yeah apologies for that, totally my fault! I've fixed the treeview plug, so as long as you're on the latest version before you upgrade this shouldn't be a problem. I think this issue can be closed @skorphil.

skorphil commented 6 months ago

Thanks for suggestions. Currently dont have time to kill, so havent tried these yet

I think i did install only default plugins(from onboarding files). Treeview is not a standard plugin, so prob it is not the main cause of an issue.

Anyway will disable updates for future use, cause it is a disappointing failure and do not want to get this again.

Prob it will be good idea to remove recommendation to use the watchtower from SB documentation, so new users will not face such an issues