[PATCH] BUG/MEDIUM: namespace: fix fd leak in master-worker mode
When namespaces are used in the configuration, the respective namespace handles
are opened during config parsing and stored in an ebtree for lookup later.
Unfortunately, when the master process re-execs itself these file descriptors
were not closed, effectively leaking the fds and preventing destruction of
namespaces no longer present in the configuration.
This change fixes this issue by opening the namespace file handles as
close-on-exec, making sure that they will be closed during re-exec.
---
src/namespace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/namespace.c b/src/namespace.c
index 8a2e5a7b1..cfb81ba0f 100644
--- a/src/namespace.c
+++ b/src/namespace.c
@@ -24,7 +24,7 @@ static int open_named_namespace(const char *ns_name)
{
if (chunk_printf(, "/var/run/netns/%s", ns_name) < 0)
return -1;
- return open(trash.area, O_RDONLY);
+ return open(trash.area, O_RDONLY | O_CLOEXEC);
}
static int default_namespace = -1;
@@ -33,7 +33,7 @@ static int init_default_namespace()
{
if (chunk_printf(, "/proc/%d/ns/net", getpid()) < 0)
return -1;
- default_namespace = open(trash.area, O_RDONLY);
+ default_namespace = open(trash.area, O_RDONLY | O_CLOEXEC);
return default_namespace;
}
--
2.23.0
Re: [PATCH] improving github experience, kindly ask people to reproduce bugs on latest haproxy
Hello Patrick, > I dunno, I've personally never been fond of it when bug reporters are blindly > asked to upgrade to the latest version. Everything you are saying is relevant for a support environment, like the mailing list or discourse. However the bug tracker is not a support forum, it's a bug tracker only. We need factual data, everything else belongs to the support channels. We needed this to file known bugs and features requests so we stop forgetting about them in the stream of emails and to coordinate fixes of known, confirmed bugs. Nobody is saying that problems need to be reported on Github. People seeking help ought to report their issues to the mailing list. If on the other hand those people are willing to file a bug report - and this implies some groundwork for them - then that's great, because it helps us. However it needs to be clear that the issue tracker in Github is not a support forum, and that filing a report will needs some ground work. It is also *always* a good idea to discuss an issue on the ML first, before filing an issue. But if you are unable to reproduce the problem on the latest release, your report definitely belongs to the mailing list. > In corporate environments, it can be difficult to perform such upgrades. > Sometimes these issues are only reproducible in production environments. I know that. But that's not a bug report, it's a support request and it belongs to the mailing list. Acked-by: Lukas Tribus Lukas
Re: [PATCH] improving github experience, kindly ask people to reproduce bugs on latest haproxy
*From:* Илья Шипицин [mailto:chipits...@gmail.com] *Sent:* Thursday, September 19, 2019, 15:10 EDT *To:* HAProxy *Subject:* [PATCH] improving github experience, kindly ask people to reproduce bugs on latest haproxy hello, please find attached patch Ilya Shipitsin I dunno, I've personally never been fond of it when bug reporters are blindly asked to upgrade to the latest version. Sometimes the request is justified, such as when the project maintainers have reason to believe the bug is fixed, or if the version is years old. But otherwise it can causes difficulties for the reporter. In corporate environments, it can be difficult to perform such upgrades. Sometimes these issues are only reproducible in production environments. So by asking them to upgrade, you're making them go through the difficulty, and potentially cause impact to their clients. And because that process can take a while, it's possible that by the time they do complete the upgrade, another version has been released. I personally also find the use of heavy bug templates, with nuanced little checkboxes to be annoying. In this case more so because we already ask them to provide the version information, which answers the question the checkbox is for. And the checkbox "yes i'm on the latest" might be accurate at the time of submission, but can become out of date. Now all that said, I'm not against encouraging people to try a later version if available. Just that I don't think it should be the expectation. -Patrick
How to set cookie in server-template config line?
When you specify multiple server like below, I get how to put the cookie and its value, but how to specify the cookie value in a server-template configuration. Because there you have one line that could match multiple servers. So putting a static value there, does not make sense. backend bk_web balance roundrobin cookie JSESSIONID prefix nocache server s1 192.168.10.11:80 check cookie s1 server s2 192.168.10.21:80 check cookie s2 https://www.haproxy.com/blog/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/
[PR] minor: a type error
Dear list! Author: ArthurMa <4406art...@gmail.com> Number of patches: 1 This is an automated relay of the Github pull request: minor: a type error Patch title(s): minor: a type error Link: https://github.com/haproxy/haproxy/pull/291 Edit locally: wget https://github.com/haproxy/haproxy/pull/291.patch && vi 291.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/291.patch | git am - Description: Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
