Cloudron Forum

[image: 1773162529545-img_0030.jpeg]

We found that a specific IP address 172.18.0.5 was for some reason always unpingable from the host. IPs before and after worked fine. I never could get to the bottom of it. A workaround was to simply squat on that IP address docker run -d --network cloudron --ip 172.18.0.5 --name test-block cloudron/base:5.0.0 sleep infinity After that everything worked. I ruled out all the obvious things : checking the firewall rules, interfaces, even recreated docker entirely from scratch. Total mystery.

Given that you got a 400 status code error, did penpot server logs reveal anything about this?

That is intentional behavior. Given that task info is very little data as such, this is unnecessary microoptimization with the downside of essentially losing audit logs from the past. On a modern system having tables with 10ks of rows in mysql should really not be an issue. How that would result in constant disk I/O without actually doing much, seems I think unrelated? If this is causing such high disk I/O I think maybe something is off in the mysql server settings instead. Do you have more analysis or info on that buffer pool activity relating to the tasks table?

@girish Great

@dsp76 I think if this happens sporadically it is a bug in the remote service provider. Have you asked their support already if this issue is known?

I cannot really reproduce this on 9.1, but there was no specific fix implemented recently.

@jdaviescoates Pretty much, yes. But it can be used for sharing with friends / sharing with people you trust though. Just give them a docker registry app password and they can put it in their cloudrons and then install via the versions file.

There is a lot of information here, but I think it got all a bit too mixed together making it unclear what might actually case the disk I/O. For a start, upserting sessions in mysql does not mean it would sync to disk all the time, so this may or may not be related. Also it is unclear to me when and why how much disk I/O is expected and when it is an issue. So it becomes even harder to properly respond here. Maybe we can try to separate the issues mainly first focusing on the potentially unnecessary session creation by the healtheck and that also ideally one application at a time. Maybe you can create those issues at the individual app packages to track those better, otherwise those issues easily get lost until such time we have resources to look into those.

Hello @phneutre Did you setup the wildcard alias according to the docs? https://docs.cloudron.io/packages/discourse/#incoming-email-setup For unique addresses per category, setup mail aliases for forum@YourMailDomain.TLD. For a category named offtopic, create a mail alias like forum@YourMailDomain.TLD. Create a wildcard mail alias * to choose any category name freely.

Hello @n8n users @brutalbirdie debugged this issue and found the issue. https://github.com/n8n-io/n8n/issues/26748#issuecomment-4031286237 We will update the Cloudron N8N app soon to fix this issue.

We solved this in the end by adding some clean up to the GitLab runner's after_script in our .gitlab-ci.yml file: before_script: - stat -c %m /tmp - du -sh /tmp - ls /tmp -la - export XDG_CACHE_HOME=$(mktemp -d) # Each job leaks files into the gitlab-runner's private /tmp after_script: - rm -rf $XDG_CACHE_HOME - du -sh /tmp - ls /tmp -la - find /tmp -mindepth 1 -maxdepth 1 -user gitlab-runner -exec rm -rf {} + - du -sh /tmp - ls /tmp -la We could see the files that got left over when we added the logging lines.

Hi, I see the fix has been merged and the latest update (1.13.2) was applied on my instance yet I cannot open my drive files maybe a workaround is needed to export our files and re-import them, I'm not sure what to do but it's frustrating to not access my files for a few weeks now. I'm sorry to ask again for support, but it's very annoying. Thanks in advance!