Cloudron Forum

@subven In this case, the Mastodon server is a personal instance. The disk space isn't an issue (now!) - I'm shunting all the media into an S3 bucket.

I'm aware that other Cloudron services need memory. Because there's swap on the box as well, I'm giving Mastodon 2GB, which is seemingly fine as long as it doesn't run any of those maintenance scripts.

But, if Mastodon isn't capable of being run in 2GB properly, my own suggestion would be to ( at least) warn Cloudron users with that sort of memory that it won't run properly.

@nebulon Cloudron automatically gave Mastodon 512MB, which clearly wasn't enough. I've given it 2GB. That seems not enough either! Yikes.

The box is a 2 GB Memory / 1 AMD vCPU / 50 GB Disk

@subven said in terminal goes blank/crashed?:

Is your hardware appropriate?

That one question doesn't appear to have an obvious answer - I don't know. (Nowhere does it tell me what appropriate hardware might be!)

But I don't see anything in the log files; I'll do the journalctl test next time I give it a go.

I'm opening the Mastodon terminal from Cloudron, and it allows me to use some bin/tootctl commands perfectly happily.

However, if you try doing a relatively taxing one - like this one for example...

RAILS_ENV=production bin/tootctl media refresh --domain=mastodon.nz --verbose

...then it runs for 30 seconds or so, and then the terminal screen goes blank (with the header still visible). I think it crashes most of the app - it seems to make everything grind to a halt and even Cloudron seems to be inoperable for a few minutes.

This is a bit of a pain, to be honest. Is there any way I can find out what's going wrong? I can't see anything obvious in the logs, but I'm unsure which log to look at.

I've given Mastodon 2GB and 75% CPU capacity.

@scooke I'll report back! As long as you've copied everything over, then you can remove public/system.

@girish Hmm.

We give the app a chance to handle well-known. If it doesn't, we try to handle it

Not sure this is what's happening.

If I visit https://social.crid.land/.well-known/webfinger?resource=acct:james@crid.land

The Mastodon server log returns:

Nov 11 18:30:54 (ipaddress) - - [11/Nov/2022:08:30:54 +0000] "GET /.well-known/webfinger?resource=acct:james@crid.land HTTP/1.1" 200 264 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"

It's an HTTP 200 OK response. It's handled the .well-known entirely correctly.

The Cloudron server logs consistently also says:

GET /well-known-handler/webfinger?resource=acct:james@crid.land 404 Not Found No custom well-known config 1.252 ms - 71

So, for some reason, Cloudron has not noticed that the .well-known has been correctly handled, and is also triggering. (Not quite sure where the 404 goes.)

I think this is an error (and a bug in Cloudron). Code should not be executing on a successful web request. How do I report this?

For @redegelde to know: this is not a bug in Mastodon (or, indeed, generated by it). Which probably explains why I couldn't find the well-known-handler in the Mastodon codebase!

@redegelde I'm seeing this issue as well.

As @nebulon says, "the well known uri should actually be /.well-known/... " but /well-known-handler/ is the script on the bot that handles the call to /.well-known/, so that's all fine.

As @girish says, the call to your webfinger (or my webfinger) request does work fine, too. The response is exactly what it should be. But it is also accompanied by this error in the logs.

So, I think...

1. It's an error appearing in your logs
2. It doesn't matter, because the actual call is handled fine.

I think what's happening here is that it's looking for a custom .well-known configuration, not finding one, and then using the default response. So everything's fine - but the error shouldn't be appearing in the logs.. at least, that's how I'm reading it.