Xenial has reached its end of standard support.
** Changed in: haproxy (Ubuntu Xenial)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service
** Merge proposal linked:
https://code.launchpad.net/~hloeung/content-cache-charm/+git/content-cache-charm/+merge/382981
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service
Looks like HAProxy's 'hard-stop-after'[1] config might be the solution
to this.
"""
Defines the maximum time allowed to perform a clean soft-stop.
This may be used to ensure that the instance will quit even if connections
remain opened during a soft-stop (for example with long timeouts for a
** Merge proposal linked:
https://code.launchpad.net/~hloeung/content-cache-charm/+git/content-cache-charm/+merge/382557
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service
Saw this elsewhere, on Bionic:
| root 6522 0.0 0.7 2089380 2035060 ? Ss Mar11 0:36
/usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -sf 60208
12488 19796 -x /run/haproxy/admin.sock
| haproxy 19796 0.0 0.5 8374612 1518588 ? Ssl Mar12 370:39 \_
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: haproxy (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
| haproxy:
| Installed: 1.8.8-1ubuntu0.9
| Candidate: 1.8.8-1ubuntu0.9
| Version table:
| *** 1.8.8-1ubuntu0.9 500
| 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64
Packages
| 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
Packages
|
** Changed in: haproxy (Ubuntu)
Status: Expired => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service haproxy reload sometimes fails to pick up new TLS certificates
To
** Changed in: haproxy (Ubuntu)
Status: Expired => New
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to haproxy in Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service haproxy reload sometimes fails to pick up new TLS
[Expired for haproxy (Ubuntu) because there has been no activity for 60
days.]
** Changed in: haproxy (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Paride, sorry for the late reply - summer holidays.
1). Unfortunately it's a rare one, and I'm not sure exactly what state
the service needs to be in, in order to trigger the bug.
2). I believe the pastebin in comment #7 is representative, and that the
PIDs don't change, but rather new
Going over the details from comment #7
This is the state before the reload:
ubuntu@foo:~$ ps auxfwww | grep haproxy
root 1346 0.0 0.0 4356 684 ?Ss May22 0:00
/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p
/run/haproxy.pid
haproxy 2210 0.0 0.2 42644
Going over the details from comment #7
This is the state before the reload:
ubuntu@foo:~$ ps auxfwww | grep haproxy
root 1346 0.0 0.0 4356 684 ?Ss May22 0:00
/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p
/run/haproxy.pid
haproxy 2210 0.0 0.2 42644
Hi Barry,
I tried again to reproduce the issue on Xenial, but without success. I
tested by 'reloading' the service several times, and in all the reloads
the PIDs of the haproxy processes did change, as expected given the
version of haproxy currently in Xenial.
In order to investigate the issue
It was marked Incomplete in #4, so there's new detail in #5, #7 and #8 -
I just missed re-opening it until now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service haproxy reload
Is there any new detail to the re-opening of the case?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service haproxy reload sometimes fails to pick up new TLS certificates
To manage
** Changed in: haproxy (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service haproxy reload sometimes fails to pick up new TLS certificates
Hi Barry,
Glad that you have a workaround, but I don't think we nailed the
problem. You are now using the 'restart' action, which is stronger than
a 'reload', and I bet that a 'service haproxy restart' would have worked
too. The 'restart' action fully stops and then starts the service, while
Never mind, here it is on Xenial:
https://pastebin.ubuntu.com/p/3zbQdnTBtF/
There's nothing relevant to haproxy in syslog, but here's the relevant
lines from /var/log/haproxy.log:
https://pastebin.ubuntu.com/p/HJT3WRc8Dw/
While the proxy processes apparently did stop, the pid 2215 process did
Something similar came up today on a Trusty instance, the WARNING lines
are possibly relevant here. To be clear, no certificates were involved
in this case, but I did catch the old processes still running after a
reload:
ubuntu@foo:~$ ps auxf | grep haproxy
ubuntu 10790 0.0 0.0 10480
Note that there is a systemd wrapper process in xenial:
411 ?Ss 0:00 /usr/sbin/haproxy-systemd-wrapper -f
/etc/haproxy/haproxy.cfg -p /run/haproxy.pid
413 ?S 0:00 \_ /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p
/run/haproxy.pid -Ds
432 ?Ss 0:00
Note that there is a systemd wrapper process in xenial:
411 ?Ss 0:00 /usr/sbin/haproxy-systemd-wrapper -f
/etc/haproxy/haproxy.cfg -p /run/haproxy.pid
413 ?S 0:00 \_ /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p
/run/haproxy.pid -Ds
432 ?Ss 0:00
I'm marking this report a Incomplete for now, as we still miss some
pieces of information needed to determine if this is actually a bug in
Ubuntu. After providing them please change the bug status back to New,
and we will look at it again. Thank you!
** Changed in: haproxy (Ubuntu)
Status:
Hi,
I see you are using service(1) to reload haproxy. The service command
has been written to manage SysV scripts, but nowadays it prefers calling
systemctl when possible. You quoted that:
After looking around for many days the issue was that "reload"
operation created a new process without
This is haproxy 1.6.3-1ubuntu0.2 on Xenial/16.04 running on amd64
hardware.
Reproduction steps:
1. Install haproxy and configure it to use a TLS certificate
2. Renew and replace that certificate
3. Run 'service haproxy reload'
4. Sometimes this starts serving the new certificate, sometimes it
Thank you for taking the time to report this bug and helping to make
Ubuntu better.
When you update with details, please make sure to provide full
reproduction steps and include details of the Ubuntu release and package
versions you used. When done, please change the bug status back to New,
and
26 matches
Mail list logo
