Re: VTest issue when built on Ubuntu 20.04
пт, 31 июл. 2020 г. в 14:29, Willy Tarreau : > On Fri, Jul 31, 2020 at 12:18:14PM +0500, ??? wrote: > > Hello, > > > > I see permanent error on Ubuntu 20.04 / s390 > > > > https://travis-ci.com/github/chipitsine/haproxy/jobs/366958312#L623 > > > > I will report to VTest, but if anyone has an idea, please let me know. > > it is a blocker for upgrading to Ubuntu 20.04 > > It's the first time I notice this one. I was about to ask if it also > fails with ZLIB (thinking it could have been a bug in SLZ) but I'm > seeing that it's already ZLIB. So maybe there's an issue in the way > zlib is used (either by us or by vtest) on s390. I don't have many > ideas for now :-/ > both SLZ and ZLIB fail in the same way > > Willy >
Re: missing date() fetcher in lua api in haproxy 2.2
Le 29/07/2020 à 01:29, James Brown a écrit : In earlier versions of haproxy, the txn.f object had a `date()` method when called from a fetch context which returned the current unix timestamp. In HAproxy 2.2, this method is removed. [...] My best guess is that this is related to ae6f125c You're right, the date() method if no longer exposed because of this commit. This is obviously unexpected. But not so simple to fix. In fact, some sample fetches have a check function to validate arguments. If this function is considered as unsafe, mainly because some arguments may be freed, the sample fetch is ignored when the lua global context is initialized. I guess it may be fixed by duplicating argument strings when necessary. This way all fetches could be exposed. I'll try to work on it. -- Christopher Faulet
Re: [ANNOUNCE] haproxy-1.9.16
On Fri, Jul 31, 2020 at 03:15:07PM +0200, Tim Düsterhus wrote: > Christopher, > Willy, > > Am 31.07.20 um 14:14 schrieb Christopher Faulet: > > The 1.9 branch is EOL now. Thus, it is the last 1.9 release. No further > > release > > should be expected. It contains all pending patches marked to be backported > > to > > the 1.9 to leave it in a proper state. Have a look at the changelog below > > for > > the complete list of fixes. > > > > You should have no reason to deploy it in a production environment. Use the > > 2.0 > > or above instead. No specific support should no longer be expected on the > > 1.9. > > This branch will not receive fixes anymore. > > > > Thanks everyone for you help and your contributions ! > > Don't forget to update the color in the version table on haproxy.org Good catch, thanks for the reminder, now done! Willy
[ANNOUNCE] haproxy-2.3-dev2
Hi, HAProxy 2.3-dev2 was released on 2020/07/31. It added 44 new commits after version 2.3-dev1. As usual in the early cycle, many of them are fixes that also affect the latest stable branch, but given that there were enough to crash the process in various ways, those starting to play with 2.3-dev will probably express a noticeable preference for this one :-) Aside bugs, we're starting to get more cleanups in the code, doc and CI. Lua 5.4 support was now added (it builds and a few tests were run, we'll see over the long term). The TCP rulesets expiration date didn't mix well with Lua because that last one could have a longer one and cause loops, or a shorter one and cause other issues. Now a dedicated expiration date is used in these rulesets and we might extend this to other places which were abusing the initial ana_timeout field which was originally meant to wait for data having to be analysed, and quickly abused by tarpits and others requiring a timer. A few optimizations at the connection layer were performed to save a few useless syscalls, and a few debugging entries were added to help us better spot abnomalies. We've had some design discussions with a few developers, observing that certain historic designs are still resisting the recent evolutions, namely at the connection layer, and really need to be dismantled and seriously reworked. These are the ones responsible for the bugs that take us ages to figure and fix. Thus, it should be expected that the next few versions will start to be a bit more chaotic. I'd also like to start changing a few defaults next week. We've seen that setting a server's pool-low-conn to roughly twice the number of threads yielded very good performance with high connection reuse rate and low overall connection count. That could become a default. I'd also like to enable edge-triggered epoll by default (it's off for now but I've been running it for a while since it was added in 2.2 and didn't see any issue yet). I'd also like to do more extensive testing on tune.sched.low-latency to see when it improves performance and when it lowers it, and decide if we should enable it by default or not, depending on the more commonly expected case. Another point to discuss is the "log-send-hostname" directive. Historically haproxy has been sending logs without hostnames, until Joe Williams added configurable support for this 10 years ago. Nowadays it seems that all those dealing with logs prefer to centralize them and seeing "localhost" or even nothing in their logs becomes confusing. The "log-send-hostname" directive allows to place the current host name in the logs, where it's expected by the syslog standard. The thing is, this option is not "on"/"off", but it is on when present, and either uses the hostname or the optional argument. So we don't have any elegant way to disable it. Thus I think it would make sense to enable it by default but we need to find a way to disable it (including passing "none" in the optional field normally dedicated to the host if everyone agrees). Or maybe "no log-send-hostname" would work like for many positional options. I'm interested in getting feedback on this so that we can change it before the last minute and we have time to see any issue it could cause. And the last point for today is that this week I took some time to move the wiki to its own repository so that it's now possible to grant access to more contributors (https://github.com/haproxy/wiki/wiki). It was kept as a regular github wiki so that we can benefit from the easy editor in the browser for those less familiar with Git. My view on this tool is that anyone who regularly participates to the project, for example by responding others' questions here or on Discourse, or by maintaining packages for a distro, is trustable enough to have a write access there. The only thing I'm asking for is to take care of not destroying others' contents (and ask for help if it happens by mistake). But it's a wiki so it's expected to be somewhat of a bazaar anyway. If some are interested, just drop me a private e-mail and I'll send you an invite (I haven't found how to simply request an access for a user). Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Wiki : https://github.com/haproxy/wiki/wiki Sources : http://www.haproxy.org/download/2.3/src/ Git repository : http://git.haproxy.org/git/haproxy.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy.git Changelog: http://www.haproxy.org/download/2.3/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog : Baruch Siach (1): BUILD: tools: fix build with static only toolchains Christopher Faulet (19): BUG/MAJOR: dns: Make the do-resolve action
Re: [ANNOUNCE] haproxy-1.9.16
Christopher, Willy, Am 31.07.20 um 14:14 schrieb Christopher Faulet: > The 1.9 branch is EOL now. Thus, it is the last 1.9 release. No further > release > should be expected. It contains all pending patches marked to be backported > to > the 1.9 to leave it in a proper state. Have a look at the changelog below for > the complete list of fixes. > > You should have no reason to deploy it in a production environment. Use the > 2.0 > or above instead. No specific support should no longer be expected on the > 1.9. > This branch will not receive fixes anymore. > > Thanks everyone for you help and your contributions ! Don't forget to update the color in the version table on haproxy.org Best regards Tim Düsterhus
[ANNOUNCE] haproxy-2.0.17
Hi, HAProxy 2.0.17 was released on 2020/07/31. It added 19 new commits after version 2.0.16. It's not much, nothing is likely to hit anybody who was not already hit, but we thought it was worth flushing the pipe. In short (some of them copied from the 2.1 announce): - various DNS fixes (do-resolve was not thread-safe, would spin if called as a final action, and there were memory leaks). - spliced transfers could occasionally stall on certain sizes due to an FD not always being re-enabled. - the memcmp() fix for ebtrees failed to build on libmusl due to a missing include. - better fix for the potential connection freezes on mux-h1 that were fixed in 2.0.16. - risk of possible infinite loop on H2 in legacy mode when transferring truncated chunked responses. It's been there since 1.9, indicating that almost nobody uses legacy anymore, which is great. - "server" directives in peers and rings wouldn't resolve if an FQDN was used, because they used to call str2sa_range() with resolve=0 like the regular servers. Sadly, no error was spotted there so that would only result in failed connection attempts. In addition, compatibility support for Lua 5.4 was backported so that those who prefer to use 2.0 on their latest distros do not experience biuld issues. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Wiki : https://github.com/haproxy/wiki/wiki Sources : http://www.haproxy.org/download/2.0/src/ Git repository : http://git.haproxy.org/git/haproxy-2.0.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-2.0.git Changelog: http://www.haproxy.org/download/2.0/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog : Christopher Faulet (12): REGEST: Add reg tests about error files BUG/MEDIUM: mux-h2: Emit an error if the response chunk formatting is incomplete BUG/MAJOR: dns: Make the do-resolve action thread-safe BUG/MEDIUM: dns: Release answer items when a DNS resolution is freed BUG/MEDIUM: mux-h1: Wakeup the H1C in h1_rcv_buf() if more data are expected BUG/MEDIUM: mux-h1: Disable the splicing when nothing is received BUG/MINOR: debug: Don't dump the lua stack if it is not initialized MEDIUM: lua: Add support for the Lua 5.4 BUG/MEDIUM: dns: Don't yield in do-resolve action on a final evaluation BUG/MINOR: tcp-rules: Set the inspect-delay when a tcp-response action yields MINOR: connection: Preinstall the mux for non-ssl connect MINOR: stream-int: Be sure to have a mux to do sends and receives Emeric Brun (1): BUG/MEDIUM: resolve: fix init resolving for ring and peers section. Olivier Houchard (1): BUG/MINOR: threads: Don't forget to init each thread toremove_lock. Willy Tarreau (5): BUILD: ebtree: fix build on libmusl after recent introduction of eb_memcmp() MINOR: pools: increase MAX_BASE_POOLS to 64 BUILD: thread: add parenthesis around values of locking macros BUG/MINOR: cfgparse: don't increment linenum on incomplete lines SCRIPTS: announce-release: add the link to the wiki in the announce messages ---
[ANNOUNCE] haproxy-2.1.8
Hi, HAProxy 2.1.8 was released on 2020/07/31. It added 82 new commits after version 2.1.7. It's been more than a month since previous version, so fixes have started to accumulate, for sure. I'll try to summarize since most of these were already mentioned over the last 2.2 releases: - various DNS fixes (do-resolve was not thread-safe, would spin if called as a final action, and there were memory leaks). - missing memory barriers on certain threaded operations that essentially affect non-x86 platforms (x86 is "forgiving") - risk of looping (and abort) on channels that's triggered at least by Lua cosockets attempting to read a complete line from truncated contents. - spliced transfers could occasionally stall on certain sizes due to an FD not always being re-enabled. - the memcmp() in ebtree was dangerous as it could read past the end on implementations that read multiple bytes at a time. - FastCGI received a few fixes (small memory leak, risk of blocking on empty stderr records, logs occasionally sent to the wrong stream, query string being unexpectedly url-decoded). - the hdr_ip() sample fetch could fail to properly parse an IPv4 address due to a missing NUL character delimiter. - loggers will not wait long on the writev() lock anymore, instead they'll drop the log after a few hundreds attempts. This will prevent the process from stalling then the watchdog killing the FD is mapped to an on-disk file that stalls writes. - upgraded HTTP requests (e.g. websocket) were experiencing a pause at the beginning of the transfer. - some spliced transfers of an exact buffer size could terminate on a timeout because there was no more attempt to read input past the end, hence detect the pending shutdown. - there was a case of high CPU usage on splicing over HTTP/1 because the connection and the stream were waking each other up on absence of data. - string comparisons with patterns (ACLs, ...) were performed by adding a trailing nul character but didn't check if it would fit, occasionally causing crashes (e.g. comparison with ALPN). Now short patterns are duplicated first. - pattern matching was still not thread-safe against parallel modifications (set-map, del-map etc). - "server" directives in peers and rings wouldn't resolve if an FQDN was used, because they used to call str2sa_range() with resolve=0 like the regular servers. Sadly, no error was spotted there so that would only result in failed connection attempts. - in case of parsing errors, the state file would not be properly closed, and could even remain uninitialized. - the crt-list parser could abort and fail in error after the first warning - the "clear map" CLI operation could sometimes take so long on extremely large maps that the watchdog could trigger. Now it proceeds in small batches and lets the traffic flow normally. - the "show sess" CLI operation could endlessly dump new streams if they arrive fast enough (just like the pretty old "netstat -a"). Now instead it will dump up to the last known stream at the moment is entered, which means that instead of dumping more streams than reality, it may dump a bit less if certain died in between. But it's now safe for use in scripts and automated reports. In addition, compatibility support for Lua 5.4 was backported so that those who prefer to use 2.1 on their latest distros do not experience issues. The "http-request deny" rules now support status codes 404, 410 and 413. Yves' patch to allow spaces to be escaped on the CLI was finally backported so that if you need to update user-agent strings via the CLI you will at last be able to (just prepend a backslash in front of them). A few other minor issues were addressed, and that's about all! It was long but not that scary. Usual stuff, nobody loves to deploy on Friday, but those still experiencing issues on 2.1.7 might prefer to upgrade. Most of those who reported the issues above are already running fine on a fixed snapshot and given that there's little overlap between bugs and nothing really dramatic, if you're on 2.1.7 and are not experiencing any of the issues above, it can wait until next week or your return from vacation. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Wiki : https://github.com/haproxy/wiki/wiki Sources : http://www.haproxy.org/download/2.1/src/ Git repository : http://git.haproxy.org/git/haproxy-2.1.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-2.1.git Changelog: http://www.haproxy.org/download/2.1/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ Willy --- Complete changelog :
[ANNOUNCE] haproxy-1.9.16
Hi, HAProxy 1.9.16 was released on 2020/07/31. It added 86 new commits after version 1.9.15. The 1.9 branch is EOL now. Thus, it is the last 1.9 release. No further release should be expected. It contains all pending patches marked to be backported to the 1.9 to leave it in a proper state. Have a look at the changelog below for the complete list of fixes. You should have no reason to deploy it in a production environment. Use the 2.0 or above instead. No specific support should no longer be expected on the 1.9. This branch will not receive fixes anymore. Thanks everyone for you help and your contributions ! Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/1.9/src/ Git repository : http://git.haproxy.org/git/haproxy-1.9.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-1.9.git Changelog: http://www.haproxy.org/download/1.9/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ --- Complete changelog : Christopher Faulet (24): BUG/MINOR: check: Update server address and port to execute an external check MINOR: checks: Add a way to send custom headers and payload during http chekcs BUG/MINOR: checks: Respect the no-check-ssl option BUG/MEDIUM: server/checks: Init server check during config validity check BUG/MINOR: checks/server: use_ssl member must be signed BUG/MEDIUM: checks: Always initialize checks before starting them BUG/MINOR: checks: Compute the right HTTP request length for HTTP health checks BUG/MINOR: checks: Remove a warning about http health checks BUG/MINOR: sample: Set the correct type when a binary is converted to a string BUG/MINOR: config: Make use_backend and use-server post-parsing less obscur BUG/MINOR: cache: Don't needlessly test "cache" keyword in parse_cache_flt() BUG/MINOR: checks: Respect check-ssl param when a port or an addr is specified BUG/MINOR: server: Fix server_finalize_init() to avoid unused variable BUG/MEDIUM: lua: Reset analyse expiration timeout before executing a lua action BUG/MEDIUM: hlua: Lock pattern references to perform set/add/del operations BUG/MINOR: proto-http: Fix detection of NTLM for the legacy HTTP version MINOR: spoe: Don't systematically create new applets if processing rate is low BUG/MEDIUM: pattern: Add a trailing \0 to match strings only if possible BUG/MINOR: backend: Remove CO_FL_SESS_IDLE if a client remains on the last server BUG/MEDIUM: mux-h1: Continue to process request when switching in tunnel mode BUG/MEDIUM: channel: Be aware of SHUTW_NOW flag when output data are peeked BUG/MEDIUM: mux-h2: Emit an error if the response chunk formatting is incomplete BUG/MEDIUM: dns: Release answer items when a DNS resolution is freed BUG/MINOR: tcp-rules: Set the inspect-delay when a tcp-response action yields Dragan Dosen (1): BUG/MEDIUM: ssl: fix the id length check within smp_fetch_ssl_fc_session_id() Emeric Brun (3): BUG/MINOR: peers: fix internal/network key type mapping. BUG/MINOR: logs: prevent double line returns in some events. BUG/MEDIUM: logs: fix trailing zeros on log message. Gaetan Rivet (1): BUG/MINOR: checks: chained expect will not properly wait for enough data Jerome Magnin (3): BUG/MINOR: ssl: default settings for ssl server options are not used DOC: option logasap does not depend on mode BUILD: select: only declare existing local labels to appease clang Miroslav Zagorac (1): BUG/MINOR: spoe: correction of setting bits for analyzer Nathan Neulinger (1): BUG/MINOR: lua: Add missing string length for lua sticktable lookup Olivier Doucet (1): DOC: Improve documentation on http-request set-src Olivier Houchard (1): BUG/MEDIUM: http-ana: Handle NTLM messages correctly. Ryan O'Hara (1): BUG/MINOR: systemd: Wait for network to be online Tim Duesterhus (5): BUG/MINOR: cfgparse: Abort parsing the current line if an invalid \x sequence is encountered BUG/MEDIUM: fetch: Fix hdr_ip misparsing IPv4 addresses due to missing NUL BUG/MINOR: http_act: don't check capture id in backend (2) BUG/MINOR: sample: Free str.area in smp_check_const_bool BUG/MINOR: sample: Free str.area in smp_check_const_meth William Dauchy (1): BUG/MINOR: pollers: remove uneeded free in global init William Lallemand (10): REGTEST: ssl: test the client certificate authentication BUG/MEDIUM: mworker: fix the copy of options in copy_argv() BUG/MINOR: init: -x can have a parameter starting with a dash BUG/MINOR: init: -S can have a parameter starting with a dash
[ANNOUNCE] haproxy-2.2.2
Hi, HAProxy 2.2.2 was released on 2020/07/31. It added 16 new commits after version 2.2.1. It fixes some bugs in the DNS part. First, Jérome fixed a possible NULL pointer dereference leading to a segfault when a server status is updated based on a name resolution if the corresponding DNS answer contains Additional records. He also fixed a parsing error if Authority records is found in a DNS answer. Now, Authority records are just ignored. Finally, a possible spinning loop in the do- resolve action was fixed. If used in tcp-request content ruleset, it was possible to wake up the stream in loop if the inspect-delay timeout was reached on a do-resolve action because it failed to abort the resolution in this case. A segfault during sending data to the server was fixed, with the help of Luke Seelenbinder and Sander Klein. For synchronous connect, it was possible to try sending data before attaching the mux on the connection. Now, before leaving connect_server(), if the connection is fully established, the mux is attached, if necessary. Willy fixed a last minute bug in the order the mux and the transport layer are attached to the connection. The mux was installed before the transport layer, leading to a double subscribes for reveiving with two different subscribers. It is totally unexpected and one event may be lost. On the 2.2, it seems to be a latent bug only. The lua 5.4 support was added. In addition, lua actions are now aborted if they explicitly yield, returning act.YIELD, on a final evaluation. It is only relevant when used in a tcp-request or tcp-response content ruleset. Baruch Siach fixed HAProxy build with static only toolchains, such as uClibc. And at last, the QUERY_STRING FCGI parameter is no longer url-decoded, as specified in the CGI/1.1 specification. The remaining patches are minor bug-fixes and adjustments here and there as always. Please have a look at the changelog below for the complete list of fixes, and do not forget to update. Please find the usual URLs below : Site index : http://www.haproxy.org/ Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Wiki : https://github.com/haproxy/wiki/wiki Sources : http://www.haproxy.org/download/2.2/src/ Git repository : http://git.haproxy.org/git/haproxy-2.2.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-2.2.git Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ --- Complete changelog : Baruch Siach (1): BUILD: tools: fix build with static only toolchains Christopher Faulet (10): BUG/MINOR: mux-fcgi: Don't url-decode the QUERY_STRING parameter anymore BUG/MINOR: debug: Don't dump the lua stack if it is not initialized MEDIUM: lua: Add support for the Lua 5.4 BUG/MEDIUM: dns: Don't yield in do-resolve action on a final evaluation BUG/MINOR: lua: Abort execution of actions that yield on a final evaluation BUG/MINOR: tcp-rules: Preserve the right filter analyser on content eval abort BUG/MINOR: tcp-rules: Set the inspect-delay when a tcp-response action yields BUG/MEDIUM: connection: Be sure to always install a mux for sync connect MINOR: connection: Preinstall the mux for non-ssl connect MINOR: stream-int: Be sure to have a mux to do sends and receives Jerome Magnin (2): BUG/MAJOR: dns: fix null pointer dereference in snr_update_srv_status BUG/MAJOR: dns: don't treat Authority records as an error Willy Tarreau (3): SCRIPTS: announce-release: add the link to the wiki in the announce messages BUG/MEDIUM: backend: always attach the transport before installing the mux BUG/MEDIUM: tcp-checks: always attach the transport before installing the mux -- Christopher Faulet
Re: [PATCH] suppress "return value is not checked" warnings
On Fri, Jul 31, 2020 at 02:32:02PM +0500, ??? wrote: > > Probably we should proceed differently and have something like these > > for the cases where no return is desired: > > > > fcntl_noret() => unchecked fcntl() > > setsockopt_noret() => unchecked setsockopt() > > > > Both would be just static inline functions wrapping the other ones in a > > DISGUISE() if needed. > > > > Then we could change the calls above to be more explicit about the intent > > of not having a return, and less ugly to read. > > > > Do you want to try to do something like this ? > > > > those issues are not urgent. > I will try. Thank you. Do not hesitate to ask if you need help or if some parts are not clear yet. Cheers, Willy
Re: [PATCH] suppress "return value is not checked" warnings
пт, 31 июл. 2020 г. в 14:26, Willy Tarreau : > Hi Ilya, > > On Sun, Jul 26, 2020 at 03:06:06PM +0500, ??? wrote: > > From e5a49969d374e3e8e9da695dca48cb6fa82ca13d Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Sun, 26 Jul 2020 15:01:10 +0500 > > Subject: [PATCH] CLEANUP: suppress coverity warnings > > > > Coverity is not happy when return value is not examined. Those > > warnings are already marked as "Intentional", let us explicitely > > mark them with DISGUISE(..) > (...) > > - setsockopt(conn->handle.fd, IPPROTO_IP, IP_TOS, , > sizeof(tos)); > > + DISGUISE(setsockopt(conn->handle.fd, IPPROTO_IP, IP_TOS, > , sizeof(tos))); > (...) > > This is getting quite ugly over time. We already had to deal with some > of these when some libcs added a must_check attribute to some calls > like write() which we used only for debugging. > > Your change doesn't just address Coverity's caprices but could as well > serve if some libcs add this attribute later. But I don't like what the > code looks like (mainly because it becomes ubiquitous and not exceptional > anymore). > > Probably we should proceed differently and have something like these > for the cases where no return is desired: > > fcntl_noret() => unchecked fcntl() > setsockopt_noret() => unchecked setsockopt() > > Both would be just static inline functions wrapping the other ones in a > DISGUISE() if needed. > > Then we could change the calls above to be more explicit about the intent > of not having a return, and less ugly to read. > > Do you want to try to do something like this ? > those issues are not urgent. I will try. > > Thanks, > Willy >
Re: VTest issue when built on Ubuntu 20.04
On Fri, Jul 31, 2020 at 12:18:14PM +0500, ??? wrote: > Hello, > > I see permanent error on Ubuntu 20.04 / s390 > > https://travis-ci.com/github/chipitsine/haproxy/jobs/366958312#L623 > > I will report to VTest, but if anyone has an idea, please let me know. > it is a blocker for upgrading to Ubuntu 20.04 It's the first time I notice this one. I was about to ask if it also fails with ZLIB (thinking it could have been a bug in SLZ) but I'm seeing that it's already ZLIB. So maybe there's an issue in the way zlib is used (either by us or by vtest) on s390. I don't have many ideas for now :-/ Willy
Re: [PATCH] suppress "return value is not checked" warnings
Hi Ilya, On Sun, Jul 26, 2020 at 03:06:06PM +0500, ??? wrote: > From e5a49969d374e3e8e9da695dca48cb6fa82ca13d Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Sun, 26 Jul 2020 15:01:10 +0500 > Subject: [PATCH] CLEANUP: suppress coverity warnings > > Coverity is not happy when return value is not examined. Those > warnings are already marked as "Intentional", let us explicitely > mark them with DISGUISE(..) (...) > - setsockopt(conn->handle.fd, IPPROTO_IP, IP_TOS, , > sizeof(tos)); > + DISGUISE(setsockopt(conn->handle.fd, IPPROTO_IP, IP_TOS, , > sizeof(tos))); (...) This is getting quite ugly over time. We already had to deal with some of these when some libcs added a must_check attribute to some calls like write() which we used only for debugging. Your change doesn't just address Coverity's caprices but could as well serve if some libcs add this attribute later. But I don't like what the code looks like (mainly because it becomes ubiquitous and not exceptional anymore). Probably we should proceed differently and have something like these for the cases where no return is desired: fcntl_noret() => unchecked fcntl() setsockopt_noret() => unchecked setsockopt() Both would be just static inline functions wrapping the other ones in a DISGUISE() if needed. Then we could change the calls above to be more explicit about the intent of not having a return, and less ugly to read. Do you want to try to do something like this ? Thanks, Willy
Re: [PATCH] CI: rework SSL_LIB, SSL_INC in more elegant way, improve build speed by switching to stock lib for openssl-1.1.1 builds
пт, 31 июл. 2020 г. в 14:14, Willy Tarreau : > On Fri, Jul 31, 2020 at 01:01:49PM +0500, ??? wrote: > > From 2fd7431ed6e94fb48332e57ae569f194e38c1b11 Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Fri, 31 Jul 2020 12:57:33 +0500 > > Subject: [PATCH] BUILD: simplify usage of env defined variables > > > > if SLZ_INC, SLZ_LIB, ZLIB_INC, ZLIB_LIB, ADDLIB, ADDINC are defined > > as environment variables they might be picked from Makefile easy. > > No, please don't inherit environment variables in makefiles, > this is a disaster and must never ever be done. This is one > of the main problems causing builds to randomly fail at various > places and is the reason why some tools have to perform > preliminary checks to force you to unset some variables to > avoid this risk. > > The variables in the makefile were purposely defined as empty > so that they are not accidently inherited from the environment. > If anyone wants to use them from environment, it's trivial > enough to pass SSL_LIB=$SSL_LIB SSL_INC=$SSL_INC etc. > > > The same way SSL_LIB, SSL_INC are used. > > I'd rather take a patch so that SSL_LIB and SSL_INC are purposely > pre-initialized to empty values for the same reason, and to ensure > consistency! I think the only reason why it's not the case is that > given they are conditionally used we didn't notice. > oook > > Thanks! > Willy >
Re: [PATCH] typo fixes
On Thu, Jul 23, 2020 at 12:34:45AM +0500, ??? wrote: > Hello, > > another patch attached. Sorry for missing this one, applied now! thanks, Willy
Re: [PATCH] CI: rework SSL_LIB, SSL_INC in more elegant way, improve build speed by switching to stock lib for openssl-1.1.1 builds
On Fri, Jul 31, 2020 at 01:01:49PM +0500, ??? wrote: > From 2fd7431ed6e94fb48332e57ae569f194e38c1b11 Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Fri, 31 Jul 2020 12:57:33 +0500 > Subject: [PATCH] BUILD: simplify usage of env defined variables > > if SLZ_INC, SLZ_LIB, ZLIB_INC, ZLIB_LIB, ADDLIB, ADDINC are defined > as environment variables they might be picked from Makefile easy. No, please don't inherit environment variables in makefiles, this is a disaster and must never ever be done. This is one of the main problems causing builds to randomly fail at various places and is the reason why some tools have to perform preliminary checks to force you to unset some variables to avoid this risk. The variables in the makefile were purposely defined as empty so that they are not accidently inherited from the environment. If anyone wants to use them from environment, it's trivial enough to pass SSL_LIB=$SSL_LIB SSL_INC=$SSL_INC etc. > The same way SSL_LIB, SSL_INC are used. I'd rather take a patch so that SSL_LIB and SSL_INC are purposely pre-initialized to empty values for the same reason, and to ensure consistency! I think the only reason why it's not the case is that given they are conditionally used we didn't notice. Thanks! Willy
Re: [PATCH] typo fixes
ping чт, 23 июл. 2020 г. в 00:34, Илья Шипицин : > Hello, > > another patch attached. > > Ilya Shipitcin >
Re: [PATCH] suppress "return value is not checked" warnings
ping. вс, 26 июл. 2020 г. в 15:06, Илья Шипицин : > Hello, > > cleanup patch attached. > > > Ilya Shipitcin >
Re: [PATCH] CI: rework SSL_LIB, SSL_INC in more elegant way, improve build speed by switching to stock lib for openssl-1.1.1 builds
sorry, one more patch
пт, 31 июл. 2020 г. в 07:48, Willy Tarreau :
> On Fri, Jul 31, 2020 at 02:13:14AM +0500, ??? wrote:
> > Hello,
> >
> > I repaired SLZ build.
> >
> > it used to work earlier because of SSL_LIB, SSL_INC variables.
>
> Makes sense indeed, applied now, thanks!
> Willy
>
From 2fd7431ed6e94fb48332e57ae569f194e38c1b11 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Fri, 31 Jul 2020 12:57:33 +0500
Subject: [PATCH] BUILD: simplify usage of env defined variables
if SLZ_INC, SLZ_LIB, ZLIB_INC, ZLIB_LIB, ADDLIB, ADDINC are defined
as environment variables they might be picked from Makefile easy.
The same way SSL_LIB, SSL_INC are used.
So let us stop assigning above variables to empty values, that
will let make to pick env variables as is.
---
Makefile | 9 -
1 file changed, 9 deletions(-)
diff --git a/Makefile b/Makefile
index 2077ca833..4870d8ee0 100644
--- a/Makefile
+++ b/Makefile
@@ -225,11 +225,6 @@ DEBUG =
# possible.
TRACE =
- Additional include and library dirs
-# Redefine this if you want to add some special PATH to include/libs
-ADDINC =
-ADDLIB =
-
Specific macro definitions
# Use DEFINE=-Dxxx to set any tunable macro. Anything declared here will appear
# in the build options reported by "haproxy -vv". Use SILENT_DEFINE if you do
@@ -486,16 +481,12 @@ endif
ifneq ($(USE_SLZ),)
# Use SLZ_INC and SLZ_LIB to force path to zlib.h and libz.{a,so} if needed.
-SLZ_INC =
-SLZ_LIB =
OPTIONS_CFLAGS += $(if $(SLZ_INC),-I$(SLZ_INC))
OPTIONS_LDFLAGS += $(if $(SLZ_LIB),-L$(SLZ_LIB)) -lslz
endif
ifneq ($(USE_ZLIB),)
# Use ZLIB_INC and ZLIB_LIB to force path to zlib.h and libz.{a,so} if needed.
-ZLIB_INC =
-ZLIB_LIB =
OPTIONS_CFLAGS += $(if $(ZLIB_INC),-I$(ZLIB_INC))
OPTIONS_LDFLAGS += $(if $(ZLIB_LIB),-L$(ZLIB_LIB)) -lz
endif
--
2.26.2
VTest issue when built on Ubuntu 20.04
Hello, I see permanent error on Ubuntu 20.04 / s390 https://travis-ci.com/github/chipitsine/haproxy/jobs/366958312#L623 I will report to VTest, but if anyone has an idea, please let me know. it is a blocker for upgrading to Ubuntu 20.04 Cheers, Ilya Shipitcin
Re: HAProxy 1.9 Snapshot generation broken?
On Fri, Jul 31, 2020 at 09:05:09AM +0200, Tim Düsterhus wrote: > Willy, > > Am 31.07.20 um 04:22 schrieb Willy Tarreau: > >> either I am dumb or it appears that the generation of HAProxy 1.9 > >> snapshots is broken. In > >> http://www.haproxy.org/download/1.9/src/snapshot/ the newest tarball is > >> from Jun, 12th. > > > > Wow, seems you're right! However I really don't understand what's > > broken: when I start the script by hand it works, and the *only* > > Thanks. I just wanted to confirm that the Lua receive loop fix in > HAProxy 1.9 works before the last 1.9 release. It does: > https://github.com/TimWolla/haproxy-auth-request/pull/20/checks?check_run_id=930857201 Great, thank you! > > difference with other working versions is exactly the branch number > > in the BRANCH variable :-( And permissions are the same everywhere. > > > > I'll check logs in case I find anything. > > Maybe Christopher only pushed yesterday for some reason? Ah that would be very possible indeed, as I know he did quite a massive number of 1.9 backports recently, and he tends not to push them until being really certain (which I constantly complain about, since exposed code is always better tested than when kept locally). We'll try to issue several releases today before a new deluge of bugs, and to close 1.9 once for all. Thanks! Willy
Re: HAProxy 1.9 Snapshot generation broken?
Willy, Am 31.07.20 um 04:22 schrieb Willy Tarreau: >> either I am dumb or it appears that the generation of HAProxy 1.9 >> snapshots is broken. In >> http://www.haproxy.org/download/1.9/src/snapshot/ the newest tarball is >> from Jun, 12th. > > Wow, seems you're right! However I really don't understand what's > broken: when I start the script by hand it works, and the *only* Thanks. I just wanted to confirm that the Lua receive loop fix in HAProxy 1.9 works before the last 1.9 release. It does: https://github.com/TimWolla/haproxy-auth-request/pull/20/checks?check_run_id=930857201 > difference with other working versions is exactly the branch number > in the BRANCH variable :-( And permissions are the same everywhere. > > I'll check logs in case I find anything. Maybe Christopher only pushed yesterday for some reason? Best regards Tim Düsterhus
