From osa at freebsd.org.ru Sat Aug 8 21:07:03 2020 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Sun, 9 Aug 2020 00:07:03 +0300 Subject: [PATCH] Support build on NetBSD Message-ID: <20200808210703.GA6068@FreeBSD.org.ru> Hi, a couple of patches to support Unit build on NetBSD. -- Sergey A. Osokin -------------- next part -------------- --- src/nxt_conn_write.c.orig 2020-05-28 12:04:00.000000000 -0400 +++ src/nxt_conn_write.c 2020-08-08 16:49:50.752693316 -0400 @@ -266,6 +266,21 @@ res = sendfile(s, fd, &pos, size); #endif +#ifdef NXT_HAVE_NETBSD_SENDFILE + struct stat fileinfo; + void *fmem = NULL; + res = fstat(fd, &fileinfo); + if (res == 0) { + fmem = mmap(NULL, fileinfo.st_size, PROT_READ, MAP_FILE | MAP_SHARED, fd, 0); + } + if (fmem != NULL) { + res = write(s, fmem, fileinfo.st_size); + munmap(fmem, fileinfo.st_size); + } else { + res = -1; + } +#endif + return res; } -------------- next part -------------- --- auto/sendfile.orig 2020-08-08 16:00:55.378410575 -0400 +++ auto/sendfile 2020-08-08 16:16:14.270362755 -0400 @@ -5,6 +5,7 @@ NXT_HAVE_LINUX_SENDFILE=NO NXT_HAVE_FREEBSD_SENDFILE=NO +NXT_HAVE_NETBSD_SENDFILE=NO NXT_HAVE_MACOSX_SENDFILE=NO NXT_HAVE_SOLARIS_SENDFILEV=NO NXT_HAVE_AIX_SEND_FILE=NO @@ -82,6 +83,34 @@ fi fi +if [ $nxt_found = no ]; then + + # NetBSD has no sendfile(). + + nxt_feature="NetBSD sendfile()" + nxt_feature_name=NXT_HAVE_NETBSD_SENDFILE + nxt_feature_libs= + nxt_feature_test="#include + #include + #include + #include + #include + + int main() { + struct stat f; + void *m = NULL; + + fstat(-1, &f); + m = mmap(NULL, f.st_size, PROT_READ, MAP_FILE | MAP_SHARED, -1, 0); + write(-1, m, f.st_size); + munmap(m, f.st_size); + }" + . auto/feature + + if [ $nxt_found = yes ]; then + NXT_HAVE_NETBSD_SENDFILE=YES + fi +fi if [ $nxt_found = no ]; then $echo From vbart at nginx.com Thu Aug 13 21:11:23 2020 From: vbart at nginx.com (Valentin V. Bartenev) Date: Fri, 14 Aug 2020 00:11:23 +0300 Subject: Unit 1.19.0 release Message-ID: <4579164.31r3eYUQgx@vbart-laptop> Hi, I'm always happy to announce a new release of NGINX Unit, but this one's BIG. Besides the varied features and bugfixes, some breakthrough improvements were made under the hood. As you may know, Unit uses an advanced architecture that relies on dedicated processes to serve different roles in request processing. The process that handles client connections is the router. It uses asynchronous threads (one per CPU core) to accept new connections and send or receive data over already established connections in a non-blocking manner. For security and scalability, all applications run as separate processes over which you have a degree of control: https://unit.nginx.org/configuration/#process-management To talk to application processes, relay requests for actual processing, and obtain their responses, the router process uses an elaborate mechanism of inter-process communication (IPC) based on shared memory segments. The general idea is to avoid copying data between processes and minimize overhead, potentially achieving almost zero-latency application interaction. Our first implementation of this protocol used a complex algorithm to distribute requests between processes, heavily utilizing Unix socket pairs to pass synchronization control messages. In practice, this turned out rather sub-optimal due to lots of extra syscalls and overt complexity. Also, the push semantics became a serious limitation that prevented us from efficiently handling asynchronous applications. Thus, we stepped back a bit at the end of the last year to meticulously reconsider our approach to IPC, and now this tremendous work finally sees the light of day with the release of Unit version 1.19.0. Maintaining the progress achieved while working with shared memory segments, the protocol now is enhanced to bring the number of syscalls almost to zero under heavy load. We have also changed the request distribution semantics. Now, instead of pushing requests to application processes using a complex router process algorithm, we make application processes pull requests out of a shared queue anytime they're ready. This enables implementing async interfaces in applications in the most effective manner. Relying on this new approach to IPC, we shall be able to improve the performance of Go and Node.js modules in the upcoming releases, also introducing multithreading and new interfaces, such as ASGI in Python. We are obsessed over performance and will continue optimizing Unit to make it the best and brightest in every aspect. As for the other features of the release, there's an improvement in proxying: now it speaks HTTP/1.1 and accepts chunked responses from backends. Moreover, request matching rules were also upgraded to enable more complex wildcard patterns like "*/some/*/path/*.php*". Finally, we have introduced our first configuration variables. They are a small bunch at the moment, but that's to change. In a while, variables shall be sufficiently diversified and will be available in more and more options. Changes with Unit 1.19.0 13 Aug 2020 *) Feature: reworked IPC between the router process and the applications to lower latencies, increase performance, and improve scalability. *) Feature: support for an arbitrary number of wildcards in route matching patterns. *) Feature: chunked transfer encoding in proxy responses. *) Feature: basic variables support in the "pass" option. *) Feature: compatibility with PHP 8 Beta 1. Thanks to Remi Collet. *) Bugfix: the router process could crash while passing requests to an application under high load. *) Bugfix: a number of language modules failed to build on some systems; the bug had appeared in 1.18.0. *) Bugfix: time in error log messages from PHP applications could lag. *) Bugfix: reconfiguration requests could hang if an application had failed to start; the bug had appeared in 1.18.0. *) Bugfix: memory leak during reconfiguration. *) Bugfix: the daemon didn't start without language modules; the bug had appeared in 1.18.0. *) Bugfix: the router process could crash at exit. *) Bugfix: Node.js applications could crash at exit. *) Bugfix: the Ruby module could be linked against a wrong library version. Also, official packages for Fedora 32 are available now: - https://unit.nginx.org/installation/#fedora And if you'd like to know more about the features introduced recently in the previous release, see the blog posts: - NGINX Unit 1.18.0 Adds Filesystem Isolation and Other Enhancements https://www.nginx.com/blog/nginx-unit-1-18-0-now-available/ - Filesystem Isolation in NGINX Unit https://www.nginx.com/blog/filesystem-isolation-nginx-unit/ Stay tuned! wbr, Valentin V. Bartenev From L.Meren at f5.com Tue Aug 18 06:18:55 2020 From: L.Meren at f5.com (Libby Meren) Date: Tue, 18 Aug 2020 06:18:55 +0000 Subject: Unit 1.19.0 release In-Reply-To: <4579164.31r3eYUQgx@vbart-laptop> References: <4579164.31r3eYUQgx@vbart-laptop> Message-ID: <9947DF35-DD56-4644-A8F9-4207A829C320@f5.com> Congratulations to the team on this release! This will be the version participants will use in our upcoming NGINX Hackathon next month, and I'm looking forward to hearing their feedback. ---- Libby Meren | OSS Product Marketing Manager D +1-206-272-4718 M +1-425-301-0424 ?On 8/13/20, 2:11 PM, "unit on behalf of Valentin V. Bartenev" wrote: EXTERNAL MAIL: unit-bounces at nginx.org Hi, I'm always happy to announce a new release of NGINX Unit, but this one's BIG. Besides the varied features and bugfixes, some breakthrough improvements were made under the hood. As you may know, Unit uses an advanced architecture that relies on dedicated processes to serve different roles in request processing. The process that handles client connections is the router. It uses asynchronous threads (one per CPU core) to accept new connections and send or receive data over already established connections in a non-blocking manner. For security and scalability, all applications run as separate processes over which you have a degree of control: https://unit.nginx.org/configuration/#process-management To talk to application processes, relay requests for actual processing, and obtain their responses, the router process uses an elaborate mechanism of inter-process communication (IPC) based on shared memory segments. The general idea is to avoid copying data between processes and minimize overhead, potentially achieving almost zero-latency application interaction. Our first implementation of this protocol used a complex algorithm to distribute requests between processes, heavily utilizing Unix socket pairs to pass synchronization control messages. In practice, this turned out rather sub-optimal due to lots of extra syscalls and overt complexity. Also, the push semantics became a serious limitation that prevented us from efficiently handling asynchronous applications. Thus, we stepped back a bit at the end of the last year to meticulously reconsider our approach to IPC, and now this tremendous work finally sees the light of day with the release of Unit version 1.19.0. Maintaining the progress achieved while working with shared memory segments, the protocol now is enhanced to bring the number of syscalls almost to zero under heavy load. We have also changed the request distribution semantics. Now, instead of pushing requests to application processes using a complex router process algorithm, we make application processes pull requests out of a shared queue anytime they're ready. This enables implementing async interfaces in applications in the most effective manner. Relying on this new approach to IPC, we shall be able to improve the performance of Go and Node.js modules in the upcoming releases, also introducing multithreading and new interfaces, such as ASGI in Python. We are obsessed over performance and will continue optimizing Unit to make it the best and brightest in every aspect. As for the other features of the release, there's an improvement in proxying: now it speaks HTTP/1.1 and accepts chunked responses from backends. Moreover, request matching rules were also upgraded to enable more complex wildcard patterns like "*/some/*/path/*.php*". Finally, we have introduced our first configuration variables. They are a small bunch at the moment, but that's to change. In a while, variables shall be sufficiently diversified and will be available in more and more options. Changes with Unit 1.19.0 13 Aug 2020 *) Feature: reworked IPC between the router process and the applications to lower latencies, increase performance, and improve scalability. *) Feature: support for an arbitrary number of wildcards in route matching patterns. *) Feature: chunked transfer encoding in proxy responses. *) Feature: basic variables support in the "pass" option. *) Feature: compatibility with PHP 8 Beta 1. Thanks to Remi Collet. *) Bugfix: the router process could crash while passing requests to an application under high load. *) Bugfix: a number of language modules failed to build on some systems; the bug had appeared in 1.18.0. *) Bugfix: time in error log messages from PHP applications could lag. *) Bugfix: reconfiguration requests could hang if an application had failed to start; the bug had appeared in 1.18.0. *) Bugfix: memory leak during reconfiguration. *) Bugfix: the daemon didn't start without language modules; the bug had appeared in 1.18.0. *) Bugfix: the router process could crash at exit. *) Bugfix: Node.js applications could crash at exit. *) Bugfix: the Ruby module could be linked against a wrong library version. Also, official packages for Fedora 32 are available now: - https://unit.nginx.org/installation/#fedora And if you'd like to know more about the features introduced recently in the previous release, see the blog posts: - NGINX Unit 1.18.0 Adds Filesystem Isolation and Other Enhancements https://www.nginx.com/blog/nginx-unit-1-18-0-now-available/ - Filesystem Isolation in NGINX Unit https://www.nginx.com/blog/filesystem-isolation-nginx-unit/ Stay tuned! wbr, Valentin V. Bartenev _______________________________________________ unit mailing list unit at nginx.org https://mailman.nginx.org/mailman/listinfo/unit From lhmwzy at 126.com Thu Aug 27 05:21:02 2020 From: lhmwzy at 126.com (lhmwzy) Date: Thu, 27 Aug 2020 13:21:02 +0800 (CST) Subject: Can't be configured under DragonFlyBSD(realpath: libtinfo.so: No such file or directory) Message-ID: <654dd9b3.2af8.1742e5cb902.Coremail.lhmwzy@126.com> # git pull #./configure php --module=php73 --config=/usr/local/bin/php-config --lib-path=/usr/local/lib configuring PHP module checking for PHP ... found realpath: libtinfo.so: No such file or directory # find / -name libtinfo.so /usr/local/lib/libtinfo.so #uname -a DragonFly gxdb 5.6-RELEASE DragonFly v5.6.0.1.g3d5034-RELEASE #0: Tue Jun 18 09:09:55 CST 2019 root at gxdb:/usr/obj/usr/src/sys/lhmwzy x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.nateldemoura at f5.com Thu Aug 27 13:43:06 2020 From: t.nateldemoura at f5.com (Tiago de Bem) Date: Thu, 27 Aug 2020 13:43:06 +0000 Subject: Can't be configured under DragonFlyBSD(realpath: libtinfo.so: No such file or directory) In-Reply-To: <654dd9b3.2af8.1742e5cb902.Coremail.lhmwzy@126.com> References: <654dd9b3.2af8.1742e5cb902.Coremail.lhmwzy@126.com> Message-ID: <9B6067D6-063A-43FA-A897-CFF6268C2C63@f5.com> Hi, Could you please provide the output of the command below? cc --print-file-name=libtinfo.so and also: $ which realpath If the command above returns nothing (exit 1), then also provide the output of `readlink --help` ? Thanks for reporting this. -- i4k From lhmwzy at 126.com Sun Aug 30 02:55:04 2020 From: lhmwzy at 126.com (lhmwzy) Date: Sun, 30 Aug 2020 10:55:04 +0800 (CST) Subject: Can't be configured under DragonFlyBSD(realpath: libtinfo.so: No such file or directory) In-Reply-To: <654dd9b3.2af8.1742e5cb902.Coremail.lhmwzy@126.com> References: <654dd9b3.2af8.1742e5cb902.Coremail.lhmwzy@126.com> Message-ID: <668d4ab9.680.1743d4a280d.Coremail.lhmwzy@126.com> # cc --print-file-name=libtinfo.so libtinfo.so # which realpath /bin/realpath # readlink --help readlink: illegal option -- - usage: readlink [-fn] [file ...] Hi, Could you please provide the output of the command below? cc --print-file-name=libtinfo.so and also: $ which realpath If the command above returns nothing (exit 1), then also provide the output of `readlink --help` ? Thanks for reporting this. -- i4k -------------- next part -------------- An HTML attachment was scrubbed... URL: