@girish said in ECONNREFUSED:
@MarchinBunny yes, that should work. But I have to say we haven't gotten any WP related ticket today atleast.
I will try again.
@girish said in ECONNREFUSED:
@MarchinBunny yes, that should work. But I have to say we haven't gotten any WP related ticket today atleast.
I will try again.
@girish said in ECONNREFUSED:
@MarchinBunny I think you will have to contact us at support@cloudron.io , so we can debug further. It's not clear why it hangs. I think something WordPress related.
I sent a support message through the cloudron interface, will that work?
@girish said in ECONNREFUSED:
@MarchinBunny it seems the app is getting stuck on start up. Can you please try this:
Put the app in recovery mode. You do this by Repair -> Enable Recovery Mode
Then, open a web terminal. Run
/app/pkg/start.sh
. Looks like it is getting stuck after updating redis configuration.If above gets stuck ^C it and then can you run
sudo -u www-data -i -- /app/pkg/wp --path=/app/data/public/ --skip-themes --skip-plugins core is-installed
? Does it hang?
It still hangs, though I am not sure if sudo -u www-data -i -- /app/pkg/wp --path=/app/data/public/ --skip-themes --skip-plugins core is-installed
is doing anything.
@nebulon said in ECONNREFUSED:
If you follow the app logs (not system logs) in the logviewer and then restart the app, it should reveal more error details as the app is starting up.
Ya, that's where I have been looking. Here is what the complete logs look like as it's starting. I see no other error. That error toward the bottom just repeats infinitely till I turn the app off. Also, I changed out some information to "x"s. Not sure what to keep private so I just did it with anything that seemed important. Though might have been unnecessary as it look encrypted but hey, better safe than sorry.
Anyway, let me know if you see something I don't. Cause that's the only error I see.
Jul 24 12:48:17 box:settings initCache: pre-load settings
Jul 24 12:48:17 box:taskworker Starting task 9461. Logs are at /home/yellowtent/platformdata/logs/35c7b265-e93e-4fb1-bb62-54ee4de0269d/apptask.log
Jul 24 12:48:17 box:apptask run: startTask installationState: pending_start runState: running
Jul 24 12:48:17 box:tasks update 9461: {"percent":10,"message":"Starting app services"}
Jul 24 12:48:17 Starting supervisor
Jul 24 12:48:17 box:tasks update 9461: {"percent":35,"message":"Starting container"}
Jul 24 12:48:18 2023-07-24 16:48:18,220 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
Jul 24 12:48:18 2023-07-24 16:48:18,220 INFO Included extra file "/etc/supervisor/conf.d/redis-service.conf" during parsing
Jul 24 12:48:18 2023-07-24 16:48:18,220 INFO Included extra file "/etc/supervisor/conf.d/redis.conf" during parsing
Jul 24 12:48:18 2023-07-24 16:48:18,232 INFO RPC interface 'supervisor' initialized
Jul 24 12:48:18 2023-07-24 16:48:18,232 CRIT Server 'inet_http_server' running without any HTTP authentication checking
Jul 24 12:48:18 2023-07-24 16:48:18,232 INFO RPC interface 'supervisor' initialized
Jul 24 12:48:18 2023-07-24 16:48:18,232 CRIT Server 'unix_http_server' running without any HTTP authentication checking
Jul 24 12:48:18 2023-07-24 16:48:18,232 INFO supervisord started with pid 1
Jul 24 12:48:18 box:tasks update 9461: {"percent":80,"message":"Configuring reverse proxy"}
Jul 24 12:48:18 => Changing permissions
Jul 24 12:48:18 box:reverseproxy providerMatchesSync: subject=CN = thatmarchingbunny.com domain=thatmarchingbunny.com issuer=C = US, O = Let's Encrypt, CN = R3 wildcard=false/true prod=true/true issuerMismatch=false wildcardMismatch=false match=true
Jul 24 12:48:18 box:reverseproxy expiryDate: subject=CN = thatmarchingbunny.com notBefore=May 28 21:10:28 2023 GMT notAfter=Aug 26 21:10:27 2023 GMT daysLeft=33.18204351851852
Jul 24 12:48:18 box:reverseproxy needsRenewal: false. force: false
Jul 24 12:48:18 box:reverseproxy ensureCertificate: thatmarchingbunny.com acme cert exists and is up to date
Jul 24 12:48:18 box:reverseproxy writeAppLocationNginxConfig: writing config for "thatmarchingbunny.com" to /home/yellowtent/platformdata/nginx/applications/35c7b265-e93e-4fb1-bb62-54ee4de0269d/thatmarchingbunny.com.conf with options {"sourceDir":"/home/yellowtent/box","vhost":"thatmarchingbunny.com","hasIPv6":true,"ip":"172.xx.xx.xx","port":80,"endpoint":"app","redirectTo":null,"certFilePath":"/home/yellowtent/platformdata/nginx/cert/thatmarchingbunny.com.cert","keyFilePath":"/home/yellowtent/platformdata/nginx/cert/thatmarchingbunny.com.key","robotsTxtQuoted":null,"cspQuoted":null,"hideHeaders":[],"proxyAuth":{"enabled":false,"id":"35c7b265-e93e-4fb1-bb62-54ee4de0269d","location":"/"},"upstreamUri":"","ocsp":true,"hstsPreload":false}
Jul 24 12:48:18 box:shell reload spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx
Jul 24 12:48:18 box:tasks update 9461: {"percent":100,"message":"Done"}
Jul 24 12:48:18 box:taskworker Task took 1.78 seconds
Jul 24 12:48:18 box:tasks setCompleted - 9461: {"result":null,"error":null}
Jul 24 12:48:18 box:tasks update 9461: {"percent":100,"result":null,"error":null}
Jul 24 12:48:19 => Updating db settings
Jul 24 12:48:19 2023-07-24 16:48:19,235 INFO spawned: 'redis' with pid 11
Jul 24 12:48:19 2023-07-24 16:48:19,241 INFO spawned: 'redis-service' with pid 12
Jul 24 12:48:19 11:C 24 Jul 2023 16:48:19.270 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Jul 24 12:48:19 11:C 24 Jul 2023 16:48:19.271 # Redis version=6.0.16, bits=64, commit=00000000, modified=0, pid=11, just started
Jul 24 12:48:19 11:C 24 Jul 2023 16:48:19.272 # Configuration loaded
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.277 * Running mode=standalone, port=6379.
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.278 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.280 # Server initialized
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.281 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.283 * Loading RDB produced by version 6.0.16
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.284 * RDB age 67328 seconds
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.285 * RDB memory usage when created 0.78 Mb
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.286 * DB loaded from disk: 0.003 seconds
Jul 24 12:48:19 11:M 24 Jul 2023 16:48:19.287 * Ready to accept connections
Jul 24 12:48:19 Redis service endpoint listening on http://:::3000
Jul 24 12:48:19 Success: Updated the constant 'DB_HOST' in the 'wp-config.php' file with the value 'mysql:3306'.
Jul 24 12:48:19 Success: Updated the constant 'DB_NAME' in the 'wp-config.php' file with the value 'xxxxxxxxxxxxxxxx'.
Jul 24 12:48:20 => Healtheck error: Error: connect ECONNREFUSED 172.xx.xx.xx:80
Jul 24 12:48:20 Success: Updated the constant 'DB_USER' in the 'wp-config.php' file with the value 'xxxxxxxxxxxxxxxx'.
Jul 24 12:48:20 Success: Updated the constant 'DB_PASSWORD' in the 'wp-config.php' file with the value 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'.
Jul 24 12:48:20 => Updating redis settings
Jul 24 12:48:20 Success: Updated the constant 'WP_REDIS_HOST' in the 'wp-config.php' file with the value 'redis-35c7b265-e93e-4fb1-bb62-54ee4de0269d'.
Jul 24 12:48:20 Success: Updated the constant 'WP_REDIS_PORT' in the 'wp-config.php' file with the value '6379'.
Jul 24 12:48:20 Success: Updated the constant 'WP_REDIS_PASSWORD' in the 'wp-config.php' file with the value 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'.
Jul 24 12:48:20 2023-07-24 16:48:20,726 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Jul 24 12:48:20 2023-07-24 16:48:20,728 INFO success: redis-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
Jul 24 12:48:30 => Healtheck error: Error: connect ECONNREFUSED 172.xx.xx.xx:80
Jul 24 12:48:40 => Healtheck error: Error: connect ECONNREFUSED 172.xx.xx.xx:80
Jul 24 12:48:50 => Healtheck error: Error: connect ECONNREFUSED 172.xx.xx.xx:80
Yes, I am sure I am looking at the right log. As for my exact issue, the app will no longer start. It just says "Not Responding" and in the logs it just keep repeating that same healthcheck error.
I have been running the website for years and never had a problem with it up till this point. As I said, I noticed things felt a bit sluggish and so I looked and noticed some out of memory messages that seems to have only started occurring about a week and a half ago. 7/12/2023 is the first time it appears under Notifications. So, I tried increasing the memory limit. And as soon as I did that, I could no longer start it up anymore and the error keeps repeating in the logs "Healtheck error: Error: connect ECONNREFUSED 172.xx.xx.xx:80" (I put the x's there to hide the full address)
Also, I have not made any changes outside of that memory limit. Which I tried to put back to what it was prior and didn't help. I also don't see any other errors. And again, I tried backups as well... and even that's not working.
Hello, I seem to be having an issue with my Wordpress website. In my logs I get this error.
Healtheck error: Error: connect ECONNREFUSED
Prior to this occuring I noticed my site was running a bit slow, and saw the app had run out of memory. So I tried resizing how much memory it has access to and since then it's had this issue. Tried setting it back to what it was previously. Tried a backup. Tried restarting the app and the server. Nothing seems to be working for me.
@timconsidine said in pricing too high:
@scooke said in pricing too high:
Don't listen to ppl asking for cheaper - they have options already. Stay true to your Cloudron course!
If they can't afford it, then they shouldn't buy it or try to ruin it for those who are happy to pay for it.
No one wants to ruin anything for those who are happy to pay for it. Asking for more options hurts no one.
Honestly, I am going to echo what has already been said. I do think the pricing is a bit too steep if you are just using Cloudron for personal use. Plus, the lack of payment options is pretty frustrating since I lack a credit card and mainly use paypal.
But ya, $15 per month for the annual subscription is a ton of money since in my case I probably would only use one additional app, or two at most. It's one of the reasons I just have never bothered with the subscription. It would be nice to be able to use more than 2, but it's just not worth it.
I wouldn't even mind paying a lot of money up front one time (like $100 or so) if it meant permanently increasing the limit to 5, and anything above that would still require the subscription.
Ok last reply for this issue as I think you can mark it solved. The environment variables do seem to be working now from what I can tell. I guess my initial tests just for some reason didn't work. But I did get an email today. So it works.
Thanks for the help. Appreciate it.
Ok, so it didn't work. I wrote an issue report on their github.
@girish said in Due date email notifications:
@MarchinBunny Can you check if email itself is working in Wekan? You can do this in Wekan's Admin Panel -> Email -> Send test mail.
It seems https://github.com/wekan/wekan/commit/5084cddf37ba16ce0855f8575c39f5e62d1b7f67#diff-3254677a7917c6c01f55212f86c57fbf is the commit that introduced the feature. The defaults are as you pointed out already. So, it's probably an upstream bug if it doesn't work. Can you ask them how to test this feature?
Yes, I have verified that sending a test email does work. I will mess with the env file and see if that works. With that said, I noticed you added "NOTIFY_DUE_DAYS_BEFORE_AND_AFTER=2" when it should be "NOTIFY_DUE_DAYS_BEFORE_AND_AFTER=2,0"
There was a commit that changed it so you can specify multiple days. For example, the 2 is for 2 days before it's due, and the 0 is on the day it's due. It's explained here.
https://github.com/wekan/wekan/commit/e60926f8471c05f50877f46568554e7b2f24815a#diff-4e5e90c6228fd48698d074241c2ba760
I already edited it myself so I will let you know if it works or not. Sadly since I can only specify the hour the email is sent out, it means I can really only test it once every hour XD. Hopefully it works the first time. Crossing my fingers lol.
If it doesn't I will check with them and see what's up.
@girish said in Due date email notifications:
@MarchinBunny This feature should work out of the box if Wekan supports it. Does it not work? What is the setting that you mention in docker-compose.yml? Cloudron does not use docker compose, we have our own packaging.
Nope, I don't think it works out of the box from what I can tell. I certainly have never received an email for due dates. If you scroll through the file I mentioned, there is a section called "==== EMAIL DUE DATE NOTIFICATION =====" Below that you will see the settings are commented out with hashtags. Here is a copy and paste of the specific section I am talking about.
# ==== EMAIL DUE DATE NOTIFICATION =====
# https://github.com/wekan/wekan/pull/2536
# System timelines will be showing any user modification for
# dueat startat endat receivedat, also notification to
# the watchers and if any card is due, about due or past due.
#
# Notify due days, default is None, 2 days before and on the event day
#- NOTIFY_DUE_DAYS_BEFORE_AND_AFTER=2,0
#
# Notify due at hour of day. Default every morning at 8am. Can be 0-23.
# If env variable has parsing error, use default. Notification sent to watchers.
#- NOTIFY_DUE_AT_HOUR_OF_DAY=8
Wekan is capable of sending out email notifications for due dates. However it seems the setting is located in docker-compose.yml which is unwritable as far as I can tell. What would be the solution to this?