Disable backlog on container start/restart.

[roman-vynar]

Addresses #187, #234

Sending the backlog does not really make sense on container restart or stop/start. Usually, you have those logs already and do not need duplicate ones.

[ebr]

@roman-vynar: it was previously mentioned in #187 and/or #201 that backlogs are needed on start because the container might have output logs before logspout has had a chance to connect. That's why #201 implements this as an env. var flag.
(off topic: your city is the loveliest place in the world :))

[roman-vynar]

@ebr then 2 things:

• what if there are too much pending logs at that moment, sending them all could very expensive
• when syslog connection is failed, we do not send logs anyway and obviously skip them

So the flag does not solve the above 2 issues. I would say it is better to have an option to send existing logs somehow else if needed on start.

P.S. offtopic: hah thanks, have you been there? 😆

[ebr]

@roman-vynar i agree this PR fixes the issue, though in my opinion it's better to provide a runtime flag, in case one relies on being certain that no log lines are lost from the beginning of the container start (and is prepared to deal with expensive sending & duplicates). But this is up to maintainers to decide, of course.

offtop: i grew up there :)

[michaelshobbs]

Perhaps we should only set this to false on restart and have a true case on start. Thoughts?

[michaelshobbs]

Just saw your previous conversation. I think I'd like to keep backlog set to true on start for now. That at least then doesn't break the current expectation.

[roman-vynar]

We can create an option then, if someone needs to re-send them.

Leaving it on start will not help as you can stop/start and it is all sent again.

[michaelshobbs]

An option is fine with me.

[michaelshobbs]

@roman-vynar is that something you're able to add here? if not, no worries but wanted to check before I run with this.

[michaelshobbs]

See comments inline

[davidnortonjr]

@michaelshobbs #201 works great in my fork (just because somebody already did the work to make it configurable). My vote would be to merge that one.

[michaelshobbs]

I concur. I'll go with #201 unless @roman-vynar has any objection

[roman-vynar]

@michaelshobbs thanks 👍