FWIW : our updates are automated, so all we care about on haproxy
reloads/restarts is
the exit code - stdout/stderr are dead to us.
But the service.c ha_warning() + send_log() doubling up was chewing up
/var/log/ space.
Hoping there was a way to shut up all the Heroku "changed its IP"
[WARNING]s noise showing
up in /var/log/syslog+messages (Debian), we found systemd's recent
StandardError= idiom and
created an /etc/systemd/system/haproxy.service.d/override.conf ("systemctl
edit haproxy"), with :
[Service]
StandardError=null
"systemctl daemon-reload" , "systemctl reload-or-restart haproxy" - no joy
(systemd 247.3-7+deb11u1).
Installed systemd/bullseye-backports (251.3-1~bpo11+1) - and the noise is
now gone. Phew ...
On Thu, Nov 10, 2022 at 11:39 AM Jim Freeman <[email protected]> wrote:
> Heroku, for instance, uses constantly rotating/changing pools of IPs with
> short (10s ?) TTLs.
>
> So any backends pointing to Heroku-hosted services will pretty much
> always/constantly get
> "changed its IP" [WARNING]s spewing to configured logs, plus stderr (on
> default Debian, syslog+messages
> => one for the price of three).
>
> The more Heroku et al being used, the more redundant noise to extraneous
> logs/facilities.
>
>
> https://help.heroku.com/VKRNVVF5/what-is-the-correct-dns-cname-target-for-my-custom-domains
>
> dig +short app.herokuapp.com
> top answer differs every time ...
>
> On Tue, Apr 20, 2021 at 11:00 PM Willy Tarreau <[email protected]> wrote:
>
>> On Fri, Apr 16, 2021 at 08:18:30AM -0600, Jim Freeman wrote:
>> > Root cause - haproxy intentionally double logs :
>> > https://github.com/haproxy/haproxy/blob/master/src/server.c
>> > srv_update_addr(...) { ... /* generates a log line and a warning on
>> > stderr */ ... }
>>
>> A number of such important updates (like servers going down for example)
>> are emitted both on stderr and logs. However I find it strange that the
>> resolvers complain every single second that the server changed address,
>> it sounds like something broke there and that it fails to conserve its
>> previous address (or maybe the DNS server oscillates all the time ?).
>>
>> Willy
>>
>
