Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Support
  3. Error CONNECT ECONNREFUSED wrong internal IP

Error CONNECT ECONNREFUSED wrong internal IP

Scheduled Pinned Locked Moved Solved Support
mail
12 Posts 4 Posters 1.8k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R Offline
      R Offline
      rfg
      wrote on last edited by girish
      #1

      Hi,

      I am getting this error when trying to send an email test from the admin page.

      connect ECONNREFUSED 172.18.0.7:2525

      However that's no the instance internal IP.

      I'm using an EC2 AWS with Elastic IP. On the Network page the Public IP is detected correctly, however I don't know from where is getting this internal IP.

      Thanks in advance

      girishG 1 Reply Last reply
      0
      • R rfg

        @nebulon ok I'll try that. Also I noticed this error

        554 Failure g_imap_max_limit exceeded 199990/199990 folder new
        

        It could be some big mailbox's folder?
        Is there a way to inspect/delete/move the bigger ones?

        girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by girish
        #9

        @rfg So, from what I see in the logs, there are multiple issues:

        • There seems to be logs of bouncing happening. This is expected because EC2 does not allow mails to be sent out directly. You have to setup a relay - https://docs.cloudron.io/email/#relay-outbound-mails
        • The mail container is in debug mode. Not sure if this was intentional? If you go to Services -> Mail -> Edit. Remove the debug mode. When debug mode is enabled, the mail container is not even running.
        • There is also some crash in haraka (our mail server).

        Can you try this:

        • On the server, if you go to /home/yellowtent/boxdata/mail/haraka-queue . Do you see a lot files here? If so, these are the mails that failed to deliver and it's trying to deliver them forever (well, a very long time). You can just delete all the files inside that directory and then docker restart mail

        • Remove the debug mode that I mentioned above.

        • Send test mail. Does that work now? I think EC2 allows a very small amount of mails to be sent directly but I am not 100% sure about this. If you paste the logs when it tries to send the test mail, that will help. You can do this by opening the logs window in another browser tab and then clicking send test mail in another window.

        R 1 Reply Last reply
        0
        • R rfg

          Hi,

          I am getting this error when trying to send an email test from the admin page.

          connect ECONNREFUSED 172.18.0.7:2525

          However that's no the instance internal IP.

          I'm using an EC2 AWS with Elastic IP. On the Network page the Public IP is detected correctly, however I don't know from where is getting this internal IP.

          Thanks in advance

          girishG Offline
          girishG Offline
          girish
          Staff
          wrote on last edited by girish
          #2

          @rfg this IP is in the internal docker network (docker inspect mail will give you the above IP address). If you go to Services view, is the mail service running ? If not, can you try restarting it and check sending mail afterwards?

          R 2 Replies Last reply
          0
          • girishG girish

            @rfg this IP is in the internal docker network (docker inspect mail will give you the above IP address). If you go to Services view, is the mail service running ? If not, can you try restarting it and check sending mail afterwards?

            R Offline
            R Offline
            rfg
            wrote on last edited by
            #3

            @girish thanks, restarting the server fixed it. 🙂

            1 Reply Last reply
            0
            • girishG girish

              @rfg this IP is in the internal docker network (docker inspect mail will give you the above IP address). If you go to Services view, is the mail service running ? If not, can you try restarting it and check sending mail afterwards?

              R Offline
              R Offline
              rfg
              wrote on last edited by rfg
              #4

              @girish It worked for a short time. Now is reporting same error.

              What could be wrong?

              Log:
              https://www.dropbox.com/s/f5uelj2dsl5pa4m/mail.zip?dl=0

              nebulonN 1 Reply Last reply
              0
              • R rfg

                @girish It worked for a short time. Now is reporting same error.

                What could be wrong?

                Log:
                https://www.dropbox.com/s/f5uelj2dsl5pa4m/mail.zip?dl=0

                nebulonN Offline
                nebulonN Offline
                nebulon
                Staff
                wrote on last edited by
                #5

                @rfg hm I can see the mail service crashing a few times and thus restarting, so maybe this happens too often and docker reassigns IPs. The error from the logs is:

                2022-02-17T12:33:00.000Z [INFO] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] bouncing mail: 554 Failure g_imap_max_limit exceeded 199990/199990 folder new
                2022-02-17T12:33:00.000Z [ERROR] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] Unrecognized response from upstream server: \r
                2022-02-17T12:33:00.000Z [INFO] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] bouncing mail: Unrecognized response from upstream server: \r
                2022-02-17T12:33:00.000Z [CRIT] [-] [core] Error: We are already running hooks! Fatal error!
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at Object.plugins.run_hooks (/app/code/haraka/plugins.js:431:15)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at HMailItem._bounce (/app/code/haraka/outbound/hmail.js:1285:17)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at HMailItem.bounce (/app/code/haraka/outbound/hmail.js:1274:14)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.<anonymous> (/app/code/haraka/outbound/hmail.js:699:22)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.emit (events.js:315:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.on_socket_data (/app/code/haraka/line_socket.js:25:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.emit (events.js:315:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at TLSSocket.<anonymous> (/app/code/haraka/tls_socket.js:59:18)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at TLSSocket.emit (events.js:315:20)
                2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at addChunk (internal/streams/readable.js:309:12)
                2022-02-17T12:33:00.000Z [NOTICE] [-] [core] Shutting down
                

                We have to investigate if this is something which requires a fix in haraka. Until that the previous temporary solution would have to be used 😕

                R 1 Reply Last reply
                0
                • nebulonN nebulon

                  @rfg hm I can see the mail service crashing a few times and thus restarting, so maybe this happens too often and docker reassigns IPs. The error from the logs is:

                  2022-02-17T12:33:00.000Z [INFO] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] bouncing mail: 554 Failure g_imap_max_limit exceeded 199990/199990 folder new
                  2022-02-17T12:33:00.000Z [ERROR] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] Unrecognized response from upstream server: \r
                  2022-02-17T12:33:00.000Z [INFO] [012E9F33-1E0E-4A1F-901A-C89B83E4FD2A.1794.1] [outbound] bouncing mail: Unrecognized response from upstream server: \r
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core] Error: We are already running hooks! Fatal error!
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at Object.plugins.run_hooks (/app/code/haraka/plugins.js:431:15)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at HMailItem._bounce (/app/code/haraka/outbound/hmail.js:1285:17)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at HMailItem.bounce (/app/code/haraka/outbound/hmail.js:1274:14)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.<anonymous> (/app/code/haraka/outbound/hmail.js:699:22)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.emit (events.js:315:20)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.on_socket_data (/app/code/haraka/line_socket.js:25:20)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at pluggableStream.emit (events.js:315:20)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at TLSSocket.<anonymous> (/app/code/haraka/tls_socket.js:59:18)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at TLSSocket.emit (events.js:315:20)
                  2022-02-17T12:33:00.000Z [CRIT] [-] [core]     at addChunk (internal/streams/readable.js:309:12)
                  2022-02-17T12:33:00.000Z [NOTICE] [-] [core] Shutting down
                  

                  We have to investigate if this is something which requires a fix in haraka. Until that the previous temporary solution would have to be used 😕

                  R Offline
                  R Offline
                  rfg
                  wrote on last edited by
                  #6

                  @nebulon do you think upgrading to Ubuntu 18.04 would help?

                  nebulonN 1 Reply Last reply
                  0
                  • R rfg

                    @nebulon do you think upgrading to Ubuntu 18.04 would help?

                    nebulonN Offline
                    nebulonN Offline
                    nebulon
                    Staff
                    wrote on last edited by
                    #7

                    @rfg I don't think it will make a difference here, since all those services run in their own container, not directly on the host system. However if you are still on Ubuntu 16, then yes it is still time to upgrade first to 18 and then ideally to 20 already https://docs.cloudron.io/guides/upgrade-ubuntu-18/

                    R 1 Reply Last reply
                    1
                    • nebulonN nebulon

                      @rfg I don't think it will make a difference here, since all those services run in their own container, not directly on the host system. However if you are still on Ubuntu 16, then yes it is still time to upgrade first to 18 and then ideally to 20 already https://docs.cloudron.io/guides/upgrade-ubuntu-18/

                      R Offline
                      R Offline
                      rfg
                      wrote on last edited by
                      #8

                      @nebulon ok I'll try that. Also I noticed this error

                      554 Failure g_imap_max_limit exceeded 199990/199990 folder new
                      

                      It could be some big mailbox's folder?
                      Is there a way to inspect/delete/move the bigger ones?

                      girishG 1 Reply Last reply
                      0
                      • R rfg

                        @nebulon ok I'll try that. Also I noticed this error

                        554 Failure g_imap_max_limit exceeded 199990/199990 folder new
                        

                        It could be some big mailbox's folder?
                        Is there a way to inspect/delete/move the bigger ones?

                        girishG Offline
                        girishG Offline
                        girish
                        Staff
                        wrote on last edited by girish
                        #9

                        @rfg So, from what I see in the logs, there are multiple issues:

                        • There seems to be logs of bouncing happening. This is expected because EC2 does not allow mails to be sent out directly. You have to setup a relay - https://docs.cloudron.io/email/#relay-outbound-mails
                        • The mail container is in debug mode. Not sure if this was intentional? If you go to Services -> Mail -> Edit. Remove the debug mode. When debug mode is enabled, the mail container is not even running.
                        • There is also some crash in haraka (our mail server).

                        Can you try this:

                        • On the server, if you go to /home/yellowtent/boxdata/mail/haraka-queue . Do you see a lot files here? If so, these are the mails that failed to deliver and it's trying to deliver them forever (well, a very long time). You can just delete all the files inside that directory and then docker restart mail

                        • Remove the debug mode that I mentioned above.

                        • Send test mail. Does that work now? I think EC2 allows a very small amount of mails to be sent directly but I am not 100% sure about this. If you paste the logs when it tries to send the test mail, that will help. You can do this by opening the logs window in another browser tab and then clicking send test mail in another window.

                        R 1 Reply Last reply
                        0
                        • girishG girish

                          @rfg So, from what I see in the logs, there are multiple issues:

                          • There seems to be logs of bouncing happening. This is expected because EC2 does not allow mails to be sent out directly. You have to setup a relay - https://docs.cloudron.io/email/#relay-outbound-mails
                          • The mail container is in debug mode. Not sure if this was intentional? If you go to Services -> Mail -> Edit. Remove the debug mode. When debug mode is enabled, the mail container is not even running.
                          • There is also some crash in haraka (our mail server).

                          Can you try this:

                          • On the server, if you go to /home/yellowtent/boxdata/mail/haraka-queue . Do you see a lot files here? If so, these are the mails that failed to deliver and it's trying to deliver them forever (well, a very long time). You can just delete all the files inside that directory and then docker restart mail

                          • Remove the debug mode that I mentioned above.

                          • Send test mail. Does that work now? I think EC2 allows a very small amount of mails to be sent directly but I am not 100% sure about this. If you paste the logs when it tries to send the test mail, that will help. You can do this by opening the logs window in another browser tab and then clicking send test mail in another window.

                          R Offline
                          R Offline
                          rfg
                          wrote on last edited by
                          #10

                          @girish that was it!!!

                          After deleting a bunch of files in that path everything is working fine now.

                          Yes, I enabled the email debug mode.

                          Many, many thanks, I really appreciate your support.

                          scookeS 1 Reply Last reply
                          0
                          • R rfg

                            @girish that was it!!!

                            After deleting a bunch of files in that path everything is working fine now.

                            Yes, I enabled the email debug mode.

                            Many, many thanks, I really appreciate your support.

                            scookeS Offline
                            scookeS Offline
                            scooke
                            wrote on last edited by
                            #11

                            @rfg What was IT? Which of the suggestions was the solution?

                            A life lived in fear is a life half-lived

                            R 1 Reply Last reply
                            1
                            • scookeS scooke

                              @rfg What was IT? Which of the suggestions was the solution?

                              R Offline
                              R Offline
                              rfg
                              wrote on last edited by
                              #12

                              @scooke Solution was deleting a buch of files from path:

                              /home/yellowtent/boxdata/mail/haraka-queue
                              

                              that files were created past Jan-06.

                              On that day we had an account hijacked that started sending out spam. I deactivated the account and it was working fine until past feb-16th, when email service started to crash.

                              HTH.

                              1 Reply Last reply
                              1
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                                • Login

                                • Don't have an account? Register

                                • Login or register to search.
                                • First post
                                  Last post
                                0
                                • Categories
                                • Recent
                                • Tags
                                • Popular
                                • Bookmarks
                                • Search