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.9k 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.
  • 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