<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/os, branch release-1.19.9</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Removed "ch" argument from ngx_pass_open_channel().</title>
<updated>2021-03-11T06:58:45+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2021-03-11T06:58:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=02cca547704f710f26a7480d3fa6b476b0f1dccd'/>
<id>02cca547704f710f26a7480d3fa6b476b0f1dccd</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Introduced strerrordesc_np() support.</title>
<updated>2021-03-01T17:00:45+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-03-01T17:00:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=4c5a49ce4c756cee85b27f9fe501f52adc7b9f1f'/>
<id>4c5a49ce4c756cee85b27f9fe501f52adc7b9f1f</id>
<content type='text'>
The strerrordesc_np() function, introduced in glibc 2.32, provides an
async-signal-safe way to obtain error messages.  This makes it possible
to avoid copying error messages.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The strerrordesc_np() function, introduced in glibc 2.32, provides an
async-signal-safe way to obtain error messages.  This makes it possible
to avoid copying error messages.
</pre>
</div>
</content>
</entry>
<entry>
<title>Improved maximum errno detection.</title>
<updated>2021-03-01T17:00:43+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-03-01T17:00:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=71eb19da43e3382ce97a14b6d3cd564881da37e7'/>
<id>71eb19da43e3382ce97a14b6d3cd564881da37e7</id>
<content type='text'>
Previously, systems without sys_nerr (or _sys_nerr) were handled with an
assumption that errors start at 0 and continuous.  This is, however, not
something POSIX requires, and not true on some platforms.

Notably, on Linux, where sys_nerr is no longer available for newly linked
binaries starting with glibc 2.32, there are gaps in error list, which
used to stop us from properly detecting maximum errno.  Further, on
GNU/Hurd errors start at 0x40000001.

With this change, maximum errno detection is moved to the runtime code,
now able to ignore gaps, and also detects the first error if needed.
This fixes observed "Unknown error" messages as seen on Linux with
glibc 2.32 and on GNU/Hurd.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, systems without sys_nerr (or _sys_nerr) were handled with an
assumption that errors start at 0 and continuous.  This is, however, not
something POSIX requires, and not true on some platforms.

Notably, on Linux, where sys_nerr is no longer available for newly linked
binaries starting with glibc 2.32, there are gaps in error list, which
used to stop us from properly detecting maximum errno.  Further, on
GNU/Hurd errors start at 0x40000001.

With this change, maximum errno detection is moved to the runtime code,
now able to ignore gaps, and also detects the first error if needed.
This fixes observed "Unknown error" messages as seen on Linux with
glibc 2.32 and on GNU/Hurd.
</pre>
</div>
</content>
</entry>
<entry>
<title>Cache: introduced min_free cache clearing.</title>
<updated>2020-06-22T15:03:00+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2020-06-22T15:03:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=0a683fdd9313b9796bf39442fd117beaa63a7157'/>
<id>0a683fdd9313b9796bf39442fd117beaa63a7157</id>
<content type='text'>
Clearing cache based on free space left on a file system is
expected to allow better disk utilization in some cases, notably
when disk space might be also used for something other than nginx
cache (including nginx own temporary files) and while loading
cache (when cache size might be inaccurate for a while, effectively
disabling max_size cache clearing).

Based on a patch by Adam Bambuch.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Clearing cache based on free space left on a file system is
expected to allow better disk utilization in some cases, notably
when disk space might be also used for something other than nginx
cache (including nginx own temporary files) and while loading
cache (when cache size might be inaccurate for a while, effectively
disabling max_size cache clearing).

Based on a patch by Adam Bambuch.
</pre>
</div>
</content>
</entry>
<entry>
<title>Too large st_blocks values are now ignored (ticket #157).</title>
<updated>2020-06-22T15:02:59+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2020-06-22T15:02:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6bb43361962ba9cb9d62bf3116bb9f88f8b39260'/>
<id>6bb43361962ba9cb9d62bf3116bb9f88f8b39260</id>
<content type='text'>
With XFS, using "allocsize=64m" mount option results in large preallocation
being reported in the st_blocks as returned by fstat() till the file is
closed.  This in turn results in incorrect cache size calculations and
wrong clearing based on max_size.

To avoid too aggressive cache clearing on such volumes, st_blocks values
which result in sizes larger than st_size and eight blocks (an arbitrary
limit) are no longer trusted, and we use st_size instead.

The ngx_de_fs_size() counterpart is intentionally not modified, as
it is used on closed files and hence not affected by this problem.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With XFS, using "allocsize=64m" mount option results in large preallocation
being reported in the st_blocks as returned by fstat() till the file is
closed.  This in turn results in incorrect cache size calculations and
wrong clearing based on max_size.

To avoid too aggressive cache clearing on such volumes, st_blocks values
which result in sizes larger than st_size and eight blocks (an arbitrary
limit) are no longer trusted, and we use st_size instead.

The ngx_de_fs_size() counterpart is intentionally not modified, as
it is used on closed files and hence not affected by this problem.
</pre>
</div>
</content>
</entry>
<entry>
<title>Large block sizes on Linux are now ignored (ticket #1168).</title>
<updated>2020-06-22T15:02:58+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2020-06-22T15:02:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=cd69bf51ca11a102a13ba30c2800ff4d553996bf'/>
<id>cd69bf51ca11a102a13ba30c2800ff4d553996bf</id>
<content type='text'>
NFS on Linux is known to report wsize as a block size (in both f_bsize
and f_frsize, both in statfs() and statvfs()).  On the other hand,
typical file system block sizes on Linux (ext2/ext3/ext4, XFS) are limited
to pagesize.  (With FAT, block sizes can be at least up to 512k in
extreme cases, but this doesn't really matter, see below.)
To avoid too aggressive cache clearing on NFS volumes on Linux, block
sizes larger than pagesize are now ignored.

Note that it is safe to ignore large block sizes.  Since 3899:e7cd13b7f759
(1.0.1) cache size is calculated based on fstat() st_blocks, and rounding
to file system block size is preserved mostly for Windows.

Note well that on other OSes valid block sizes seen are at least up
to 65536.  In particular, UFS on FreeBSD is known to work well with block
and fragment sizes set to 65536.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NFS on Linux is known to report wsize as a block size (in both f_bsize
and f_frsize, both in statfs() and statvfs()).  On the other hand,
typical file system block sizes on Linux (ext2/ext3/ext4, XFS) are limited
to pagesize.  (With FAT, block sizes can be at least up to 512k in
extreme cases, but this doesn't really matter, see below.)
To avoid too aggressive cache clearing on NFS volumes on Linux, block
sizes larger than pagesize are now ignored.

Note that it is safe to ignore large block sizes.  Since 3899:e7cd13b7f759
(1.0.1) cache size is calculated based on fstat() st_blocks, and rounding
to file system block size is preserved mostly for Windows.

Note well that on other OSes valid block sizes seen are at least up
to 65536.  In particular, UFS on FreeBSD is known to work well with block
and fragment sizes set to 65536.
</pre>
</div>
</content>
</entry>
<entry>
<title>Stream: fixed processing of zero length UDP packets (ticket #1982).</title>
<updated>2020-06-08T08:40:34+00:00</updated>
<author>
<name>Vladimir Homutov</name>
<email>vl@nginx.com</email>
</author>
<published>2020-06-08T08:40:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=58d1412f0df08a90cc4df9bb3e5fb8a550daf63e'/>
<id>58d1412f0df08a90cc4df9bb3e5fb8a550daf63e</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed SIGQUIT not removing listening UNIX sockets (closes #753).</title>
<updated>2020-06-01T19:31:23+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2020-06-01T19:31:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=9c3ac44de268f0cf057bc5dd67929e74c9bbc3e3'/>
<id>9c3ac44de268f0cf057bc5dd67929e74c9bbc3e3</id>
<content type='text'>
Listening UNIX sockets were not removed on graceful shutdown, preventing
the next runs.  The fix is to replace the custom socket closing code in
ngx_master_process_cycle() by the ngx_close_listening_sockets() call.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Listening UNIX sockets were not removed on graceful shutdown, preventing
the next runs.  The fix is to replace the custom socket closing code in
ngx_master_process_cycle() by the ngx_close_listening_sockets() call.
</pre>
</div>
</content>
</entry>
<entry>
<title>Win32: silenced -Wcast-function-type GCC warning (ticket #1865).</title>
<updated>2019-10-21T16:07:03+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2019-10-21T16:07:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=2393e25acb89f7434e6330a7754c076575a297fd'/>
<id>2393e25acb89f7434e6330a7754c076575a297fd</id>
<content type='text'>
With MinGW-w64, building 64-bit nginx binary with GCC 8 and above
results in warning due to cast of GetProcAddress() result to ngx_wsapoll_pt,
which GCC thinks is incorrect.  Added intermediate cast to "void *" to
silence the warning.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With MinGW-w64, building 64-bit nginx binary with GCC 8 and above
results in warning due to cast of GetProcAddress() result to ngx_wsapoll_pt,
which GCC thinks is incorrect.  Added intermediate cast to "void *" to
silence the warning.
</pre>
</div>
</content>
</entry>
<entry>
<title>Win32: improved fallback on FormatMessage() errors.</title>
<updated>2019-10-21T16:06:12+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2019-10-21T16:06:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=9aa906a684111a2f61ee841067cc0023ebcfa269'/>
<id>9aa906a684111a2f61ee841067cc0023ebcfa269</id>
<content type='text'>
FormatMessage() seems to return many errors which essentially indicate that
the language in question is not available.  At least the following were
observed in the wild and during testing: ERROR_MUI_FILE_NOT_FOUND (15100)
(ticket #1868), ERROR_RESOURCE_TYPE_NOT_FOUND (1813).  While documentation
says it should be ERROR_RESOURCE_LANG_NOT_FOUND (1815), this doesn't seem
to be the case.

As such, checking error code was removed, and as long as FormatMessage()
returns an error, we now always try the default language.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
FormatMessage() seems to return many errors which essentially indicate that
the language in question is not available.  At least the following were
observed in the wild and during testing: ERROR_MUI_FILE_NOT_FOUND (15100)
(ticket #1868), ERROR_RESOURCE_TYPE_NOT_FOUND (1813).  While documentation
says it should be ERROR_RESOURCE_LANG_NOT_FOUND (1815), this doesn't seem
to be the case.

As such, checking error code was removed, and as long as FormatMessage()
returns an error, we now always try the default language.
</pre>
</div>
</content>
</entry>
</feed>
