Request: Remove printing about "[APIv1] KEEPALIVE /api/v1/events"

[clytras]

Inside api/v1.go we see that the keepalive function uses stream.Notify("keepalive", []byte{}) to, as stated in the comment, keep connections alive.

 // keepalive sends an empty keep alive message. 
 // 
 // This not only can keep connections alive, but also will detect broken 
 // connections. Without this it is possible for the server to become 
 // unresponsive due to too many open files. 
 func (apiv1 *APIv1) keepalive() { 
    log.Println("[APIv1] KEEPALIVE /api/v1/events") 
    stream.Notify("keepalive", []byte{}) 
 } 

Which will spam an attached console with many messages like this:

Can we keep the stream.Notify("keepalive", []byte{}) which will do the job and ditch the printing log.Println("[APIv1] KEEPALIVE /api/v1/events")? Or make an enviroment variable flag option to indicate printing that line or not?

In my developer setup (and I believe in others too) I use attached containers to drive every log message to stdout and these event spam messages really bug me up.

[dbaggott]

Fyi, related to / arguably duplicate of https://github.com/mailhog/MailHog/issues/56

You can completely disable logging at the risk of losing knowledge of real errors as suggested here:

https://github.com/mailhog/MailHog/issues/56#issuecomment-376463964

[clytras]

@dbaggott thanks for the reply.

My request is NOT to turn off verbose logging, my request is about killing that useless log line I pointed out that it occurs every single minute. That log line does not offer any kind of useful information. Can you please tell me your opinion on why such a log info might be useful to developers using Mailhog?

So to clear this out, I want to have logging but I would like to get rid of that useless information about a hack regarding keeping alive the service running.

EDIT

My request might be related to https://github.com/mailhog/MailHog/issues/56#issuecomment-486800404, as I believe such information should have been logged using a DEBUG level which of course would have been turned off by default. Something like this maybe:

// Log verbosity levels example https://www.honeybadger.io/blog/golang-logging/
DebugLogger.Println("[APIv1] KEEPALIVE /api/v1/events")

But of course that assumes there has to be a log level system able to have configurable levels that users can change.

[webkp]

I can only agree @clytras. I found this issue because I am struggling with the exact same problem. It is annoying that important messages can be overlooked because of the countless [APIv1] KEEPALIVE /api/v1/events lines.

[dbaggott]

@clytras, I was just trying to be helpful in case you didn't see the related issue.

Yes, I imagine once #56 is implemented then there would be support for user configurable log levels and it would be easy to exclude the more verbose debug / info logging...

[clytras]

And you did very well @dbaggott, because https://github.com/mailhog/MailHog/issues/56 is related to this request if someone thinks that this line offers some kind of usefull information, they can keep it while debuging with setting the DEBUG logging level if https://github.com/mailhog/MailHog/issues/56 is picked and there will be a logging system with configurable levels. But again, I think that this log line needs to be deleted as it spams not only the terminal buffer and screen in case of stdout logging, but also log files with countless of useless information.

[bjbr-dev]

Im not entirely confident in GO, but I can see that there is already a debug function in https://github.com/mailhog/MailHog/blob/0441dd494b03c9255a9b8e90e3458ebb115eacff/vendor/gopkg.in/mgo.v2/log.go#L105

Can we use that instead? Happy to make a PR with that change

[bjbr-dev]

Apologies, should have looked closer at the code :) Looks like that line is actually from the mongo package used by MailHog.

There is an import statement to https://github.com/ian-kent/go-log at the top of the api file, which looks like it supports debug as well - that would be a more suitable fix :)

Any objections for me to raise a PR?

[clytras]

For anyone interested on getting rid of that annoying spam message, I've forked this and created my own Docker Hub image lytrax/mailhog with tha latest tag like lytrax/mailhog:latest.

I've tested it with Docker and Laravel Sail with different binding ports even and it works pretty well so far without spaming the output console every minute.

You can even create your own images using the Dockerfile in my forked repo which go get will download the source from my repo.

[Sam-Lane]

I agree with @clytras this log message is of no benefit and just creates noise in my logs. I would be really happy to see it removed/silenced.

[macau23]

I'd like to keep this log message, but change the log level to make it invisible by default.

[smjet]

Any ETA on this? It's been almost a year.

[olevekavitocz]

2 year without proper answer? :-D Cmon guyz help us with our paper trail test server situation :-)

[bradjones1]

2 year without proper answer? :-D Cmon guyz help us with our paper trail test server situation :-)

This is not helpful.

This is an open-source project, and for those who are complaining and enquiring about when this might change... you are more than welcome to propose a PR or hire a developer (one of the project maintainers, maybe?) to do so, for you. Nobody in open-source owes you anything if you aren't paying for it.

[fnep]

I'm currently using a custom entry point as a workaround. Not happy with it, but it works for me.

  mailserver:
    image: mailhog/mailhog
    entrypoint: ["/bin/sh", "-c", "MailHog | grep -v KEEPALIVE"]

(edited to avoid people copying the wrong version)

[olevekavitocz]

2 year without proper answer? :-D Cmon guyz help us with our paper trail test server situation :-)

This is not helpful.

This is an open-source project, and for those who are complaining and enquiring about when this might change... you are more than welcome to propose a PR or hire a developer (one of the project maintainers, maybe?) to do so, for you. Nobody in open-source owes you anything if you aren't paying for it.

And the winner of the competition for the most boring person is... @bradjones1! Gratz, buddy.

Of course we can write a PR, of course we can hire a programmer to do it for us, or we can write it ourselves (which I already did in the fork version), but that doesn't address my comment, which is that for two years this thread has been open and unanswered. We have been dealing with this problem in the company for a long time and I periodically look at possible solutions here in the abandoned topic.

I have not attacked the authors in any way and have tried to nudge them towards a solution in a very friendly way.

Thanks @fnep, we use a similar solution, and like you we are not thrilled with it.

[mfn]

I'm currently using a custom entry point as a workaround. Not happy with it, but it works for me.

I tried this one too, but I still got the output… delayed; like it was buffered. I didn't dug further, but is the output maybe sent to stderr? 🤔

I also tried this in docker compose, but I must have been doing something wrong, I still got the output; and I didn't favour this one because I still want to get regular logs:

    logging:
      driver: none

@olevekavitocz can you share your solution?

[olevekavitocz]

We use the almost same design as @fnep wrote. The application is wrapped in a docker and we filter the output from mailhog using grep -v "[APIv1] KEEPALIVE" (removes lines from the output that goes to the log) for a custom entrypoint. The filtered content is then saved to syslog.

Alternatively (older projects) we use a "custom" (fork) mailhog, where only the logging line is commented out (as @clytras originally wrote) - which I probably don't recommend.

There is also the possibility to filter the log as such at the operating system level (I have no experience with this, but similar solutions are used by companies we work with) e.g. https://github.com/syslog-ng/syslog-ng

[mfn]

Can confirm that this version finally worked; the previous grep for some reason didn't: entrypoint: ["/bin/sh", "-c", "MailHog | grep -v KEEPALIVE"]

I also wanted to disable buffering as I've noticed it (--line-buffering), but the version in the container doesn't feature it (or I missed it).

[egor83]

I wanted to disable logging altogether, so I combined @fnep's solution and @talawahtech's solution in #56 (thanks for these!) a bit, editing docker-compose.yml as follows:

mailhog:
  ...
  entrypoint: ["/bin/sh", "-c", "MailHog &>/dev/null"]