/unit/ |
H A D | .mailmap | diff 2664:c6889773b191 Tue Feb 20 00:57:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> .mailmap: Map some more personal addresses
Add more entries for Andrei and Konstantin and an entry for Dan.
Reviewed-by: Dan Callahan <d.callahan@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 2473:743741e00a16 Sat May 20 19:37:00 UTC 2023 Alejandro Colomar <alx@nginx.com> Using names in .mailmap.
In this case, Andrew always committed under the same name, so it's not strictly necessary.
This is for consistency, so that it's clearer whose is an email address. It also makes it easier to sort the names alphabetically.
Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2472:3f68ff1c058a Sat May 20 19:35:00 UTC 2023 Alejandro Colomar <alx@nginx.com> Added Alex to .mailmap.
Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> 2206:3453dbe2d665 Thu Sep 22 20:21:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Added a .mailmap file.
This file is used by git (maybe also hg) to map different identities.
It can be used to map different names/email addresses to a preferred name/email. So if you have authored/committed under different names/email addresses you can map all these to a particular name/email. Certain git commands (log, shortlog, show, blame etc) will consult this file and show the Author/Committer accordingly.
Note: This does _not_ change history, this is simply used by various commands to alter their output and can be disabled for some commands with the --no-mailmap option.
This can be useful for commands like git shortlog so that all your commits are shown under a single identity and also so people have an up to date email address should they wish to contact you. And just for overall consistency.
Seeing as I've already committed under two different email addresses (not counting this one), I've put entries in this file to map my email addresses to my @nginx.com one.
See also, gitmailmap(5).
Acked-by: Alex Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
H A D | CHANGES | diff 2707:1d63b0ce2394 Thu Feb 15 19:20:00 UTC 2024 Andrei Zeliankou <zelenkov@nginx.com> Added version 1.32.0 CHANGES diff 886:9d30c80a7935 Thu Dec 20 16:17:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Added version 1.7 CHANGES. diff 885:aae620f3dc68 Thu Dec 20 16:17:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Fixed style in CHANGES. diff 783:ded84d50e555 Thu Sep 20 15:18:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Added version 1.4 CHANGES.
|
H A D | README.md | diff 2467:28282eb943b9 Wed May 10 20:15:00 UTC 2023 Artem Konev <artem.konev@nginx.com> Fixed broken links in README. diff 302:1234ac183bea Thu Sep 07 20:59:00 UTC 2017 Valentin Bartenev <vbart@nginx.com> README: added mention of the licence in the main section. diff 301:a77ec6786276 Wed Sep 06 20:52:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> README: fixed URLs. diff 300:23a45e381cf4 Wed Sep 06 20:46:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> README: shortened description. diff 299:00479e2ccdf0 Wed Sep 06 20:19:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> README: fixed URLs. diff 298:e3d1aa2207e0 Wed Sep 06 20:14:00 UTC 2017 Andrei Belov <defan@nginx.com> README: fixed package repository paths.
|
H A D | configure | diff 2339:917f2df08b91 Fri Dec 02 17:20:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Autodetect endianness.
In configure we set NXT_HAVE_LITTLE_ENDIAN for i386, amd64 and x86_64. However that misses at least AArch64 (arm64) where it's usually run in little endian mode.
However none of that really matters as NXT_HAVE_LITTLE_ENDIAN isn't used anywhere. So why this patch?
The only place we need to explicitly know about endianness is the nxt_websocket_header_t structure where we lay it out differently depending on endianness.
This is currently done using BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN macros.
However on at least illumos (OpenSolaris / OpenIndiana) those macros are not defined and we get compiler errors due to duplicate structure members.
So let's use our own NXT_HAVE_{BIG,LITTLE}_ENDIAN macros. However it would be better to detect endianness programmatically as some architectures can run in either mode, e.g Linux used to run in big endian on PowerPC but has since switched to little endian (to match x86).
This commit adds an auto/endian script (using a slightly modified version of the test program from nginx's auto script), that checks for the endianness of the platform being built on. E.g
checking for endianness ... little endian
The next commit will switch the nxt_websocket_header_t structure over to these new macros.
Link: <https://github.com/nginx/unit/pull/298> Link: <https://developer.ibm.com/articles/l-power-little-endian-faq-trs/> Tested-by: Alejandro Colomar <alx@nginx.com> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2301:c18bcb724cec Fri Dec 02 17:20:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Autodetect endianness.
In configure we set NXT_HAVE_LITTLE_ENDIAN for i386, amd64 and x86_64. However that misses at least AArch64 (arm64) where it's usually run in little endian mode.
However none of that really matters as NXT_HAVE_LITTLE_ENDIAN isn't used anywhere. So why this patch?
The only place we need to explicitly know about endianness is the nxt_websocket_header_t structure where we lay it out differently depending on endianness.
This is currently done using BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN macros.
However on at least illumos (OpenSolaris / OpenIndiana) those macros are not defined and we get compiler errors due to duplicate structure members.
So let's use our own NXT_HAVE_{BIG,LITTLE}_ENDIAN macros. However it would be better to detect endianness programmatically as some architectures can run in either mode, e.g Linux used to run in big endian on PowerPC but has since switched to little endian (to match x86).
This commit adds an auto/endian script (using a slightly modified version of the test program from nginx's auto script), that checks for the endianness of the platform being built on. E.g
checking for endianness ... little endian
The next commit will switch the nxt_websocket_header_t structure over to these new macros.
Link: <https://github.com/nginx/unit/pull/298> Link: <https://developer.ibm.com/articles/l-power-little-endian-faq-trs/> Tested-by: Alejandro Colomar <alx@nginx.com> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 2247:baa6b9879267 Sun Nov 20 15:16:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Basic njs support.
|
/unit/auto/ |
H A D | clang | diff 701:f184ffeb0f02 Wed Jun 20 16:34:00 UTC 2018 Sergey Kandaurov <pluknet@nginx.com> Using own popcount where the compiler builtin is not available.
|
H A D | endian | diff 2339:917f2df08b91 Fri Dec 02 17:20:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Autodetect endianness.
In configure we set NXT_HAVE_LITTLE_ENDIAN for i386, amd64 and x86_64. However that misses at least AArch64 (arm64) where it's usually run in little endian mode.
However none of that really matters as NXT_HAVE_LITTLE_ENDIAN isn't used anywhere. So why this patch?
The only place we need to explicitly know about endianness is the nxt_websocket_header_t structure where we lay it out differently depending on endianness.
This is currently done using BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN macros.
However on at least illumos (OpenSolaris / OpenIndiana) those macros are not defined and we get compiler errors due to duplicate structure members.
So let's use our own NXT_HAVE_{BIG,LITTLE}_ENDIAN macros. However it would be better to detect endianness programmatically as some architectures can run in either mode, e.g Linux used to run in big endian on PowerPC but has since switched to little endian (to match x86).
This commit adds an auto/endian script (using a slightly modified version of the test program from nginx's auto script), that checks for the endianness of the platform being built on. E.g
checking for endianness ... little endian
The next commit will switch the nxt_websocket_header_t structure over to these new macros.
Link: <https://github.com/nginx/unit/pull/298> Link: <https://developer.ibm.com/articles/l-power-little-endian-faq-trs/> Tested-by: Alejandro Colomar <alx@nginx.com> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com> 2301:c18bcb724cec Fri Dec 02 17:20:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Autodetect endianness.
In configure we set NXT_HAVE_LITTLE_ENDIAN for i386, amd64 and x86_64. However that misses at least AArch64 (arm64) where it's usually run in little endian mode.
However none of that really matters as NXT_HAVE_LITTLE_ENDIAN isn't used anywhere. So why this patch?
The only place we need to explicitly know about endianness is the nxt_websocket_header_t structure where we lay it out differently depending on endianness.
This is currently done using BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN macros.
However on at least illumos (OpenSolaris / OpenIndiana) those macros are not defined and we get compiler errors due to duplicate structure members.
So let's use our own NXT_HAVE_{BIG,LITTLE}_ENDIAN macros. However it would be better to detect endianness programmatically as some architectures can run in either mode, e.g Linux used to run in big endian on PowerPC but has since switched to little endian (to match x86).
This commit adds an auto/endian script (using a slightly modified version of the test program from nginx's auto script), that checks for the endianness of the platform being built on. E.g
checking for endianness ... little endian
The next commit will switch the nxt_websocket_header_t structure over to these new macros.
Link: <https://github.com/nginx/unit/pull/298> Link: <https://developer.ibm.com/articles/l-power-little-endian-faq-trs/> Tested-by: Alejandro Colomar <alx@nginx.com> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
H A D | help | diff 2688:83a6f5cccb92 Tue Feb 06 04:20:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Wasm-wc: Wire it up to the build system
Et voila...
$ ./configure wasm-wasi-component configuring wasm-wasi-component module Looking for rust compiler ... found. Looking for cargo ... found. + wasm-wasi-component module: wasm_wasi_component.unit.so $ make install test -d /opt/unit/sbin || install -d /opt/unit/sbin install -p build/sbin/unitd /opt/unit/sbin/ test -d /opt/unit/state || install -d /opt/unit/state test -d /opt/unit || install -d /opt/unit test -d /opt/unit || install -d /opt/unit test -d /opt/unit/share/man/man8 || install -d /opt/unit/sh man/man8 install -p -m644 build/share/man/man8/unitd.8 /opt/unit/share/ma n8/ make build/src/nxt_unit.o make[1]: Entering directory '/home/andrew/src/unit' make[1]: 'build/src/nxt_unit.o' is up to date. make[1]: Leaving directory '/home/andrew/src/unit' cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml Finished release [optimized] target(s) in 0.55s install -d /opt/unit/modules install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \ /opt/unit/modules/wasm_wasi_component.unit.so
Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2247:baa6b9879267 Sun Nov 20 15:16:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Basic njs support.
|
H A D | make | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 1554:8f22edff911d Tue Aug 11 16:20:00 UTC 2020 Max Romanov <max.romanov@nginx.com> Circular queues implementations and a test.
- naive circular queue, described in the article "A Scalable, Portable, and Memory-Efficient Lock-Free FIFO Queue" by Ruslan Nikolaev: https://drops.dagstuhl.de/opus/volltexte/2019/11335/pdf/LIPIcs-DISC-2019-28.pdf - circular queue, proposed by Valentin Bartenev in the "Unit router application IPC" design draft diff 1131:ec7d924d8dfb Tue Aug 20 13:31:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Introducing websocket support in router and libunit. diff 771:f349b2d68e75 Thu Sep 20 12:05:00 UTC 2018 Igor Sysoev <igor@sysoev.ru> Added SSL/TLS support on connection level. diff 700:069b3b56cbca Wed Jun 20 16:33:00 UTC 2018 Sergey Kandaurov <pluknet@nginx.com> Using portable grep features. diff 376:b01fc4313953 Fri Oct 20 14:52:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Using the single source of Unit version. diff 375:de6b3c2778a0 Fri Oct 20 14:48:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Version bump. diff 87:ae678814949f Fri Jun 23 16:20:00 UTC 2017 Max Romanov <max.romanov@nginx.com> External Go app request processing. diff 86:3b77edf46701 Fri Jun 23 16:20:00 UTC 2017 Max Romanov <max.romanov@nginx.com> PHP app request processing. diff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring. The cycle has been renamed to the runtime.
|
H A D | njs | diff 2510:f5a5a487a669 Tue Jul 11 20:02:00 UTC 2023 Konstantin Pavlov <thresh@nginx.com> NJS: explicitely require 0.8.0 or later versions in configure. 2247:baa6b9879267 Sun Nov 20 15:16:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Basic njs support.
|
H A D | options | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2247:baa6b9879267 Sun Nov 20 15:16:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Basic njs support. diff 771:f349b2d68e75 Thu Sep 20 12:05:00 UTC 2018 Igor Sysoev <igor@sysoev.ru> Added SSL/TLS support on connection level. diff 87:ae678814949f Fri Jun 23 16:20:00 UTC 2017 Max Romanov <max.romanov@nginx.com> External Go app request processing. diff 86:3b77edf46701 Fri Jun 23 16:20:00 UTC 2017 Max Romanov <max.romanov@nginx.com> PHP app request processing.
|
H A D | save | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
H A D | sources | diff 2448:243735980417 Thu Apr 20 15:20:00 UTC 2023 Zhidao HONG <z.hong@f5.com> HTTP: added basic URI rewrite.
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from the request is preserverd. An example: "routes": [ { "match": { "uri": "/v1/test" }, "action": { "return": 200 } }, { "action": { "rewrite": "/v1$uri", "pass": "routes" } } ]
Reviewed-by: Alejandro Colomar <alx@nginx.com> diff 2448:243735980417 Thu Apr 20 15:20:00 UTC 2023 Zhidao HONG <z.hong@f5.com> HTTP: added basic URI rewrite.
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from the request is preserverd. An example: "routes": [ { "match": { "uri": "/v1/test" }, "action": { "return": 200 } }, { "action": { "rewrite": "/v1$uri", "pass": "routes" } } ]
Reviewed-by: Alejandro Colomar <alx@nginx.com> diff 2247:baa6b9879267 Sun Nov 20 15:16:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Basic njs support. diff 2246:5f4056478375 Sun Nov 20 15:15:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Var: separating nxt_tstr_t from nxt_var_t.
It's for the introduction of njs support. For each option that supports native variable and JS template literals introduced next, it's unified as template string.
No functional changes. diff 1579:c80e692dc644 Thu Aug 20 14:22:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Moved isolation related code to "nxt_isolation.c". diff 1394:20b41ebfff79 Fri Mar 06 15:28:00 UTC 2020 Igor Sysoev <igor@sysoev.ru> Round robin upstream added. diff 1131:ec7d924d8dfb Tue Aug 20 13:31:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Introducing websocket support in router and libunit. diff 774:b21709350c49 Thu Sep 20 12:27:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Controller: certificates storage interface. diff 771:f349b2d68e75 Thu Sep 20 12:05:00 UTC 2018 Igor Sysoev <igor@sysoev.ru> Added SSL/TLS support on connection level. diff 80:1b394e999c7c Fri Jun 23 16:20:00 UTC 2017 Max Romanov <max.romanov@nginx.com> Store pointer to shared memory start in buf->parent.
nxt_port_mmap_t stored in arrays and it is unsafe to store pointer to array element.
Shared memory structures and macros moved to separate header file to be used by GO package.
|
H A D | ssltls | diff 771:f349b2d68e75 Thu Sep 20 12:05:00 UTC 2018 Igor Sysoev <igor@sysoev.ru> Added SSL/TLS support on connection level.
|
H A D | summary | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2247:baa6b9879267 Sun Nov 20 15:16:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Basic njs support.
|
H A D | unix | diff 2151:fab207c6836c Sun Jun 19 12:20:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Removed code used when NXT_HAVE_POSIX_SPAWN is false.
posix_spawn(3POSIX) was introduced by POSIX.1d (IEEE Std 1003.1d-1999), and was later consolidated in POSIX.1-2001, requiring it in all POSIX-compliant systems. It's safe to assume it's always available, more than 20 years after its standardization.
Link: <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/spawn.h.html> diff 2151:fab207c6836c Sun Jun 19 12:20:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Removed code used when NXT_HAVE_POSIX_SPAWN is false.
posix_spawn(3POSIX) was introduced by POSIX.1d (IEEE Std 1003.1d-1999), and was later consolidated in POSIX.1-2001, requiring it in all POSIX-compliant systems. It's safe to assume it's always available, more than 20 years after its standardization.
Link: <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/spawn.h.html>
|
/unit/auto/modules/ |
H A D | conf | diff 2688:83a6f5cccb92 Tue Feb 06 04:20:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Wasm-wc: Wire it up to the build system
Et voila...
$ ./configure wasm-wasi-component configuring wasm-wasi-component module Looking for rust compiler ... found. Looking for cargo ... found. + wasm-wasi-component module: wasm_wasi_component.unit.so $ make install test -d /opt/unit/sbin || install -d /opt/unit/sbin install -p build/sbin/unitd /opt/unit/sbin/ test -d /opt/unit/state || install -d /opt/unit/state test -d /opt/unit || install -d /opt/unit test -d /opt/unit || install -d /opt/unit test -d /opt/unit/share/man/man8 || install -d /opt/unit/sh man/man8 install -p -m644 build/share/man/man8/unitd.8 /opt/unit/share/ma n8/ make build/src/nxt_unit.o make[1]: Entering directory '/home/andrew/src/unit' make[1]: 'build/src/nxt_unit.o' is up to date. make[1]: Leaving directory '/home/andrew/src/unit' cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml Finished release [optimized] target(s) in 0.55s install -d /opt/unit/modules install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \ /opt/unit/modules/wasm_wasi_component.unit.so
Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 87:ae678814949f Fri Jun 23 16:20:00 UTC 2017 Max Romanov <max.romanov@nginx.com> External Go app request processing. diff 86:3b77edf46701 Fri Jun 23 16:20:00 UTC 2017 Max Romanov <max.romanov@nginx.com> PHP app request processing. diff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring. The cycle has been renamed to the runtime.
|
H A D | go | diff 1344:da88d2612f96 Tue Jan 28 16:20:00 UTC 2020 Max Romanov <max.romanov@nginx.com> Go: adding main configure CFLAGS and LDFLAGS to module build flags.
This makes ASAN buildbot workers to work out-of-the-box. diff 1131:ec7d924d8dfb Tue Aug 20 13:31:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Introducing websocket support in router and libunit.
|
H A D | java | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 1673:883f2f79c2f6 Thu Oct 29 20:30:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Isolation: mounting of procfs by default when using "rootfs".
|
H A D | perl | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 780:0de745fae82c Thu Sep 20 13:34:00 UTC 2018 Sergey Kandaurov <pluknet@nginx.com> Fixed building perl on Alpine Linux.
_GNU_SOURCE is required there to expose off64_t and other types.
|
H A D | php | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 1482:90460ae5046a Wed May 20 08:18:00 UTC 2020 Remi Collet <remi@remirepo.net> PHP: building with PHP 8 (development version).
|
H A D | python | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 1673:883f2f79c2f6 Thu Oct 29 20:30:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Isolation: mounting of procfs by default when using "rootfs". diff 1624:e46b1b422545 Thu Oct 01 20:55:00 UTC 2020 Max Romanov <max.romanov@nginx.com> Python: ASGI server introduced.
This closes #461 issue on GitHub.
|
H A D | ruby | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2080:651f5a37f5b8 Thu Mar 10 20:19:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Workarounded Clang bug triggered by Ruby.
Add -fdeclspec to NXT_RUBY_CFLAGS for Clang, if it's available.
Clang incorrectly reports 1 for __has_declspec_attribute(x) in some cases, such as MacOS or Cygwin. That causes ruby code to break. ruby added -fdeclspec to their CFLAGS in 2019 to workaround this bug, since it enables __declspec() and therefore, the compiler behavior matches what it reports.
Since we don't know what are all the architectures that trigger the clang bug, let's add the flag for all of them (especially since it should be harmless).
Add this workaround only at the time of configuring the ruby module. This way we don't clutter the global NXT_CFLAGS with an unnecessary flag.
Link: unit bug <https://github.com/nginx/unit/issues/653> Link: ruby bug <https://bugs.ruby-lang.org/issues/18616> Link: LLVM bug <https://github.com/llvm/llvm-project/issues/49958> Commit: LLVM: Add -fdeclspec <d170c4b57a91adc74ca89c6d4af616a00323b12c> Commit: ruby: Use -fdeclspec <0958e19ffb047781fe1506760c7cbd8d7fe74e57> diff 1673:883f2f79c2f6 Thu Oct 29 20:30:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Isolation: mounting of procfs by default when using "rootfs". diff 1537:b472ba224472 Sat Aug 08 20:52:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Configure: verifying the Ruby library path.
An attempt to build a Ruby module for a custom Ruby installation that has the same major version as the system Ruby may unexpectedly cause the use of the system Ruby library.
This closes #449 issue on GitHub.
|
H A D | wasm-wasi-component | 2688:83a6f5cccb92 Tue Feb 06 04:20:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Wasm-wc: Wire it up to the build system
Et voila...
$ ./configure wasm-wasi-component configuring wasm-wasi-component module Looking for rust compiler ... found. Looking for cargo ... found. + wasm-wasi-component module: wasm_wasi_component.unit.so $ make install test -d /opt/unit/sbin || install -d /opt/unit/sbin install -p build/sbin/unitd /opt/unit/sbin/ test -d /opt/unit/state || install -d /opt/unit/state test -d /opt/unit || install -d /opt/unit test -d /opt/unit || install -d /opt/unit test -d /opt/unit/share/man/man8 || install -d /opt/unit/sh man/man8 install -p -m644 build/share/man/man8/unitd.8 /opt/unit/share/ma n8/ make build/src/nxt_unit.o make[1]: Entering directory '/home/andrew/src/unit' make[1]: 'build/src/nxt_unit.o' is up to date. make[1]: Leaving directory '/home/andrew/src/unit' cargo build --release --manifest-path src/wasm-wasi-component/Cargo.toml Finished release [optimized] target(s) in 0.55s install -d /opt/unit/modules install -p src/wasm-wasi-component/target/release/libwasm_wasi_component.so \ /opt/unit/modules/wasm_wasi_component.unit.so
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
/unit/docs/ |
H A D | changes.xml | diff 2707:1d63b0ce2394 Thu Feb 15 19:20:00 UTC 2024 Andrei Zeliankou <zelenkov@nginx.com> Added version 1.32.0 CHANGES diff 2448:243735980417 Thu Apr 20 15:20:00 UTC 2023 Zhidao HONG <z.hong@f5.com> HTTP: added basic URI rewrite.
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from the request is preserverd. An example: "routes": [ { "match": { "uri": "/v1/test" }, "action": { "return": 200 } }, { "action": { "rewrite": "/v1$uri", "pass": "routes" } } ]
Reviewed-by: Alejandro Colomar <alx@nginx.com> diff 2448:243735980417 Thu Apr 20 15:20:00 UTC 2023 Zhidao HONG <z.hong@f5.com> HTTP: added basic URI rewrite.
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from the request is preserverd. An example: "routes": [ { "match": { "uri": "/v1/test" }, "action": { "return": 200 } }, { "action": { "rewrite": "/v1$uri", "pass": "routes" } } ]
Reviewed-by: Alejandro Colomar <alx@nginx.com> diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2262:0bca3af03c75 Mon Oct 24 16:14:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Isolation: wired up cgroup support to the config system.
This hooks the cgroup support up to the config system so it can actually be used.
To make use of this in unit a new "cgroup" section has been added to the isolation configuration.
e.g
"applications": { "python": { "type": "python", "processes": 5, "path": "/opt/unit/unit-cgroup-test/", "module": "app",
"isolation": { "cgroup": { "path": "app/python" } } } }
Now there are two ways to specify the path, relative, like the above (without a leading '/') and absolute (with a leading '/').
In the above case the "python" application is placed into its own cgroup under CGROUP_ROOT/<main unit process cgroup>/app/python. Whereas if you specified say
"path": "/unit/app/python"
Then the python application would be placed under CGROUP_ROOT/unit/app/python
The first option allows you to easily take advantage of any resource limits that have already been configured for unit.
With the second method (absolute pathname) if you know of an already existing cgroup where you'd like to place it, you can, e.g
"path": "/system.slice/unit/python"
Where system.slice has already been created by systemd and may already have some overall system limits applied which would also apply to unit. Limits apply down the hierarchy and lower groups can't exceed the previous group limits.
So what does this actually look like? Lets take the unit-calculator application[0] and have each of its applications placed into their own cgroup. If we give each application a new section like
"isolation": { "cgroup": { "path": "/unit/unit-calculator/add" } }
changing the path for each one, we can visualise the result with the systemd-cgls command, e.g
│ └─session-5.scope (#4561) │ ├─ 6667 sshd: andrew [priv] │ ├─ 6684 sshd: andrew@pts/0 │ ├─ 6685 -bash │ ├─ 12632 unit: main v1.28.0 [/opt/unit/sbin/unitd --control 127.0.0.1:808> │ ├─ 12634 unit: controller │ ├─ 12635 unit: router │ ├─ 13550 systemd-cgls │ └─ 13551 less ├─unit (#4759) │ └─unit-calculator (#5037) │ ├─subtract (#5069) │ │ ├─ 12650 unit: "subtract" prototype │ │ └─ 12651 unit: "subtract" application │ ├─multiply (#5085) │ │ ├─ 12653 unit: "multiply" prototype │ │ └─ 12654 unit: "multiply" application │ ├─divide (#5101) │ │ ├─ 12671 unit: "divide" prototype │ │ └─ 12672 node divide.js │ ├─sqroot (#5117) │ │ ├─ 12679 unit: "sqroot" prototype │ │ └─ 12680 /home/andrew/src/unit-calculator/sqroot/sqroot │ └─add (#5053) │ ├─ 12648 unit: "add" prototype │ └─ 12649 unit: "add" application
We used an absolute path so the cgroups will be created relative to the main cgroupfs mount, e.g /sys/fs/cgroup
We can see that the main unit processes are in the same cgroup as the shell from where they were started, by default child process are placed into the same cgroup as the parent.
Then we can see that each application has been placed into its own cgroup under /sys/fs/cgroup
Taking another example of a simple 5 process python application, with
"isolation": { "cgroup": { "path": "app/python" } }
Here we have specified a relative path and thus the python application will be placed below the existing cgroup that contains the main unit process. E.g
│ │ │ ├─app-glib-cinnamon\x2dcustom\x2dlauncher\x2d3-43951.scope (#90951) │ │ │ │ ├─ 988 unit: main v1.28.0 [/opt/unit/sbin/unitd --no-daemon] │ │ │ │ ├─ 990 unit: controller │ │ │ │ ├─ 991 unit: router │ │ │ │ ├─ 43951 xterm -bg rgb:20/20/20 -fg white -fa DejaVu Sans Mono │ │ │ │ ├─ 43956 bash │ │ │ │ ├─ 58828 sudo -i │ │ │ │ ├─ 58831 -bash │ │ │ │ └─app (#107351) │ │ │ │ └─python (#107367) │ │ │ │ ├─ 992 unit: "python" prototype │ │ │ │ ├─ 993 unit: "python" application │ │ │ │ ├─ 994 unit: "python" application │ │ │ │ ├─ 995 unit: "python" application │ │ │ │ ├─ 996 unit: "python" application │ │ │ │ └─ 997 unit: "python" application
[0]: <https://github.com/lcrilly/unit-calculator>
Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 2262:0bca3af03c75 Mon Oct 24 16:14:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Isolation: wired up cgroup support to the config system.
This hooks the cgroup support up to the config system so it can actually be used.
To make use of this in unit a new "cgroup" section has been added to the isolation configuration.
e.g
"applications": { "python": { "type": "python", "processes": 5, "path": "/opt/unit/unit-cgroup-test/", "module": "app",
"isolation": { "cgroup": { "path": "app/python" } } } }
Now there are two ways to specify the path, relative, like the above (without a leading '/') and absolute (with a leading '/').
In the above case the "python" application is placed into its own cgroup under CGROUP_ROOT/<main unit process cgroup>/app/python. Whereas if you specified say
"path": "/unit/app/python"
Then the python application would be placed under CGROUP_ROOT/unit/app/python
The first option allows you to easily take advantage of any resource limits that have already been configured for unit.
With the second method (absolute pathname) if you know of an already existing cgroup where you'd like to place it, you can, e.g
"path": "/system.slice/unit/python"
Where system.slice has already been created by systemd and may already have some overall system limits applied which would also apply to unit. Limits apply down the hierarchy and lower groups can't exceed the previous group limits.
So what does this actually look like? Lets take the unit-calculator application[0] and have each of its applications placed into their own cgroup. If we give each application a new section like
"isolation": { "cgroup": { "path": "/unit/unit-calculator/add" } }
changing the path for each one, we can visualise the result with the systemd-cgls command, e.g
│ └─session-5.scope (#4561) │ ├─ 6667 sshd: andrew [priv] │ ├─ 6684 sshd: andrew@pts/0 │ ├─ 6685 -bash │ ├─ 12632 unit: main v1.28.0 [/opt/unit/sbin/unitd --control 127.0.0.1:808> │ ├─ 12634 unit: controller │ ├─ 12635 unit: router │ ├─ 13550 systemd-cgls │ └─ 13551 less ├─unit (#4759) │ └─unit-calculator (#5037) │ ├─subtract (#5069) │ │ ├─ 12650 unit: "subtract" prototype │ │ └─ 12651 unit: "subtract" application │ ├─multiply (#5085) │ │ ├─ 12653 unit: "multiply" prototype │ │ └─ 12654 unit: "multiply" application │ ├─divide (#5101) │ │ ├─ 12671 unit: "divide" prototype │ │ └─ 12672 node divide.js │ ├─sqroot (#5117) │ │ ├─ 12679 unit: "sqroot" prototype │ │ └─ 12680 /home/andrew/src/unit-calculator/sqroot/sqroot │ └─add (#5053) │ ├─ 12648 unit: "add" prototype │ └─ 12649 unit: "add" application
We used an absolute path so the cgroups will be created relative to the main cgroupfs mount, e.g /sys/fs/cgroup
We can see that the main unit processes are in the same cgroup as the shell from where they were started, by default child process are placed into the same cgroup as the parent.
Then we can see that each application has been placed into its own cgroup under /sys/fs/cgroup
Taking another example of a simple 5 process python application, with
"isolation": { "cgroup": { "path": "app/python" } }
Here we have specified a relative path and thus the python application will be placed below the existing cgroup that contains the main unit process. E.g
│ │ │ ├─app-glib-cinnamon\x2dcustom\x2dlauncher\x2d3-43951.scope (#90951) │ │ │ │ ├─ 988 unit: main v1.28.0 [/opt/unit/sbin/unitd --no-daemon] │ │ │ │ ├─ 990 unit: controller │ │ │ │ ├─ 991 unit: router │ │ │ │ ├─ 43951 xterm -bg rgb:20/20/20 -fg white -fa DejaVu Sans Mono │ │ │ │ ├─ 43956 bash │ │ │ │ ├─ 58828 sudo -i │ │ │ │ ├─ 58831 -bash │ │ │ │ └─app (#107351) │ │ │ │ └─python (#107367) │ │ │ │ ├─ 992 unit: "python" prototype │ │ │ │ ├─ 993 unit: "python" application │ │ │ │ ├─ 994 unit: "python" application │ │ │ │ ├─ 995 unit: "python" application │ │ │ │ ├─ 996 unit: "python" application │ │ │ │ └─ 997 unit: "python" application
[0]: <https://github.com/lcrilly/unit-calculator>
Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 2262:0bca3af03c75 Mon Oct 24 16:14:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Isolation: wired up cgroup support to the config system.
This hooks the cgroup support up to the config system so it can actually be used.
To make use of this in unit a new "cgroup" section has been added to the isolation configuration.
e.g
"applications": { "python": { "type": "python", "processes": 5, "path": "/opt/unit/unit-cgroup-test/", "module": "app",
"isolation": { "cgroup": { "path": "app/python" } } } }
Now there are two ways to specify the path, relative, like the above (without a leading '/') and absolute (with a leading '/').
In the above case the "python" application is placed into its own cgroup under CGROUP_ROOT/<main unit process cgroup>/app/python. Whereas if you specified say
"path": "/unit/app/python"
Then the python application would be placed under CGROUP_ROOT/unit/app/python
The first option allows you to easily take advantage of any resource limits that have already been configured for unit.
With the second method (absolute pathname) if you know of an already existing cgroup where you'd like to place it, you can, e.g
"path": "/system.slice/unit/python"
Where system.slice has already been created by systemd and may already have some overall system limits applied which would also apply to unit. Limits apply down the hierarchy and lower groups can't exceed the previous group limits.
So what does this actually look like? Lets take the unit-calculator application[0] and have each of its applications placed into their own cgroup. If we give each application a new section like
"isolation": { "cgroup": { "path": "/unit/unit-calculator/add" } }
changing the path for each one, we can visualise the result with the systemd-cgls command, e.g
│ └─session-5.scope (#4561) │ ├─ 6667 sshd: andrew [priv] │ ├─ 6684 sshd: andrew@pts/0 │ ├─ 6685 -bash │ ├─ 12632 unit: main v1.28.0 [/opt/unit/sbin/unitd --control 127.0.0.1:808> │ ├─ 12634 unit: controller │ ├─ 12635 unit: router │ ├─ 13550 systemd-cgls │ └─ 13551 less ├─unit (#4759) │ └─unit-calculator (#5037) │ ├─subtract (#5069) │ │ ├─ 12650 unit: "subtract" prototype │ │ └─ 12651 unit: "subtract" application │ ├─multiply (#5085) │ │ ├─ 12653 unit: "multiply" prototype │ │ └─ 12654 unit: "multiply" application │ ├─divide (#5101) │ │ ├─ 12671 unit: "divide" prototype │ │ └─ 12672 node divide.js │ ├─sqroot (#5117) │ │ ├─ 12679 unit: "sqroot" prototype │ │ └─ 12680 /home/andrew/src/unit-calculator/sqroot/sqroot │ └─add (#5053) │ ├─ 12648 unit: "add" prototype │ └─ 12649 unit: "add" application
We used an absolute path so the cgroups will be created relative to the main cgroupfs mount, e.g /sys/fs/cgroup
We can see that the main unit processes are in the same cgroup as the shell from where they were started, by default child process are placed into the same cgroup as the parent.
Then we can see that each application has been placed into its own cgroup under /sys/fs/cgroup
Taking another example of a simple 5 process python application, with
"isolation": { "cgroup": { "path": "app/python" } }
Here we have specified a relative path and thus the python application will be placed below the existing cgroup that contains the main unit process. E.g
│ │ │ ├─app-glib-cinnamon\x2dcustom\x2dlauncher\x2d3-43951.scope (#90951) │ │ │ │ ├─ 988 unit: main v1.28.0 [/opt/unit/sbin/unitd --no-daemon] │ │ │ │ ├─ 990 unit: controller │ │ │ │ ├─ 991 unit: router │ │ │ │ ├─ 43951 xterm -bg rgb:20/20/20 -fg white -fa DejaVu Sans Mono │ │ │ │ ├─ 43956 bash │ │ │ │ ├─ 58828 sudo -i │ │ │ │ ├─ 58831 -bash │ │ │ │ └─app (#107351) │ │ │ │ └─python (#107367) │ │ │ │ ├─ 992 unit: "python" prototype │ │ │ │ ├─ 993 unit: "python" application │ │ │ │ ├─ 994 unit: "python" application │ │ │ │ ├─ 995 unit: "python" application │ │ │ │ ├─ 996 unit: "python" application │ │ │ │ └─ 997 unit: "python" application
[0]: <https://github.com/lcrilly/unit-calculator>
Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com> diff 2247:baa6b9879267 Sun Nov 20 15:16:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Basic njs support. diff 2149:7a53238e050d Wed Jul 13 20:34:00 UTC 2022 Zhidao HONG <z.hong@f5.com> HTTP: added more variables.
This commit adds the following variables: $remote_addr, $time_local, $request_line, $status, $body_bytes_sent, $header_referer, $header_user_agent. diff 2147:7bf58b1b18c4 Wed Jul 13 20:32:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Var: dynamic variables support.
This commit adds the variables $arg_NAME, $header_NAME, and $cookie_NAME.
|
H A D | unit-openapi.yaml | diff 2707:1d63b0ce2394 Thu Feb 15 19:20:00 UTC 2024 Andrei Zeliankou <zelenkov@nginx.com> Added version 1.32.0 CHANGES
|