ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2019-05-24T06:39:14Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1050Build failure on Windows2019-05-24T06:39:14ZStephen MorrisBuild failure on WindowsCommit efff347f969cb9cdf8c520d2d393bbf6f61a2dcb failed to build on Windows:
```
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(54): error C2079: 'common' uses undefined struct 'isc_appctx' [c:\cygwin64\...Commit efff347f969cb9cdf8c520d2d393bbf6f61a2dcb failed to build on Windows:
```
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(54): error C2079: 'common' uses undefined struct 'isc_appctx' [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(113): error C2039: 'magic': is not a member of 'isc_appctx' [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(254): error C2371: 'isc_app_ctxshutdown': redefinition; different basic types [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(277): error C2371: 'isc_app_shutdown': redefinition; different basic types [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(278): error C2561: 'isc_app_shutdown': function must return a value [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(282): error C2371: 'isc_app_ctxsuspend': redefinition; different basic types [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(306): error C2371: 'isc_app_reload': redefinition; different basic types [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(307): error C2561: 'isc_app_reload': function must return a value [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(349): error C2039: 'magic': is not a member of 'isc_appctx' [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(364): error C2065: 'isc__appctx_t': undeclared identifier [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\app.c(364): error C2059: syntax error: ')' [c:\cygwin64\home\jenkins\workspace\bind9-master-win64-fast\lib\isc\win32\libisc.vcxproj]
```
See the [Jenkins log](https://jenkins.isc.org/view/BIND/job/bind9-master-win64-fast/288/) for more details. In particular, there are additional warning messages.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1049Build failure on OpenBSD2019-06-03T12:27:08ZStephen MorrisBuild failure on OpenBSDCommit 00ff7863843b34b24632f9aba90c5c0f520c6f5c failed to build on OpenBSD 6.2.
```
egcc -std=gnu99 -include /home/jenkins/workspace/bind9-master-openbsd62-64/config.h -I/home/jenkins/workspace/bind9-master-openbsd62-64 -I../.. -I./uni...Commit 00ff7863843b34b24632f9aba90c5c0f520c6f5c failed to build on OpenBSD 6.2.
```
egcc -std=gnu99 -include /home/jenkins/workspace/bind9-master-openbsd62-64/config.h -I/home/jenkins/workspace/bind9-master-openbsd62-64 -I../.. -I./unix/include -I./pthreads/include -I./include -I./include -I/home/jenkins/workspace/bind9-master-openbsd62-64/lib/dns/include -I../../lib/dns/include -I/usr/include -DISC_MEM_DEFAULTFILL=1 -DISC_LIST_CHECKINIT=1 -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -Wshadow -Werror -c siphash.c
In file included from siphash.c:36:0:
./include/isc/endian.h:82:2: error: #error Platform not supported
#error Platform not supported
^
*** Error 1 in lib/isc (Makefile:274 'siphash.o')
*** Error 1 in lib (Makefile:89 'subdirs')
*** Error 1 in /home/jenkins/workspace/bind9-master-openbsd62-64 (Makefile:96 'subdirs')
```
See the [Jenkins log](https://jenkins.isc.org/job/bind9-master-openbsd62-64/620/console) for more details.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1048Build failure on FreeBSD2019-06-03T12:27:08ZStephen MorrisBuild failure on FreeBSDCommit 8ddc54e20054e91e6e2dd32a4510a5eecc777548 failed to build on FreeBSD 11.1.
```
libtool: compile: gcc -include /usr/home/jenkins/workspace/bind9-master-freebsd11-64/config.h -I/usr/home/jenkins/workspace/bind9-master-freebsd11-64 ...Commit 8ddc54e20054e91e6e2dd32a4510a5eecc777548 failed to build on FreeBSD 11.1.
```
libtool: compile: gcc -include /usr/home/jenkins/workspace/bind9-master-freebsd11-64/config.h -I/usr/home/jenkins/workspace/bind9-master-freebsd11-64 -I../.. -I./unix/include -I./pthreads/include -I./include -I./include -I/usr/home/jenkins/workspace/bind9-master-freebsd11-64/lib/dns/include -I../../lib/dns/include -I/usr/local/include -DISC_MEM_DEFAULTFILL=1 -DISC_LIST_CHECKINIT=1 -g -O2 -pthread -I /usr/local/include -I/usr/local/include/libxml2 -I/usr/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -Wshadow -Werror -c siphash.c -fPIC -DPIC -o .libs/siphash.o
In file included from siphash.c:36:0:
./include/isc/endian.h:46:0: error: "be16toh" redefined [-Werror]
# define be16toh(x) betoh16(x)
In file included from ./include/isc/endian.h:44:0,
from siphash.c:36:
/usr/include/sys/endian.h:75:0: note: this is the location of the previous definition
#define be16toh(x) bswap16((x))
In file included from siphash.c:36:0:
./include/isc/endian.h:47:0: error: "le16toh" redefined [-Werror]
# define le16toh(x) letoh16(x)
In file included from ./include/isc/endian.h:44:0,
from siphash.c:36:
/usr/include/sys/endian.h:78:0: note: this is the location of the previous definition
#define le16toh(x) ((uint16_t)(x))
In file included from siphash.c:36:0:
./include/isc/endian.h:49:0: error: "be32toh" redefined [-Werror]
# define be32toh(x) betoh32(x)
In file included from ./include/isc/endian.h:44:0,
from siphash.c:36:
/usr/include/sys/endian.h:76:0: note: this is the location of the previous definition
#define be32toh(x) bswap32((x))
In file included from siphash.c:36:0:
./include/isc/endian.h:50:0: error: "le32toh" redefined [-Werror]
# define le32toh(x) letoh32(x)
In file included from ./include/isc/endian.h:44:0,
from siphash.c:36:
/usr/include/sys/endian.h:79:0: note: this is the location of the previous definition
#define le32toh(x) ((uint32_t)(x))
In file included from siphash.c:36:0:
./include/isc/endian.h:52:0: error: "be64toh" redefined [-Werror]
# define be64toh(x) betoh64(x)
In file included from ./include/isc/endian.h:44:0,
from siphash.c:36:
/usr/include/sys/endian.h:77:0: note: this is the location of the previous definition
#define be64toh(x) bswap64((x))
In file included from siphash.c:36:0:
./include/isc/endian.h:53:0: error: "le64toh" redefined [-Werror]
# define le64toh(x) letoh64(x)
In file included from ./include/isc/endian.h:44:0,
from siphash.c:36:
/usr/include/sys/endian.h:80:0: note: this is the location of the previous definition
#define le64toh(x) ((uint64_t)(x))
In file included from siphash.c:36:0:
siphash.c: In function 'isc_siphash24':
./include/isc/endian.h:53:21: error: implicit declaration of function 'letoh64' [-Werror=implicit-function-declaration]
# define le64toh(x) letoh64(x)
^
siphash.c:62:16: note: in expansion of macro 'le64toh'
uint64_t k0 = le64toh(key[0]);
^~~~~~~
cc1: all warnings being treated as errors
*** Error code 1
Stop.
make[2]: stopped in /usr/home/jenkins/workspace/bind9-master-freebsd11-64/lib/isc
*** Error code 1
Stop.
make[1]: stopped in /usr/home/jenkins/workspace/bind9-master-freebsd11-64/lib
*** Error code 1
```
See the [Jenkins log](https://jenkins.isc.org/view/BIND/job/bind9-master-freebsd11-64/1314/) for more details.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/kea/-/issues/620config-backend v6: relay parameter in shared-networks is not taken into accou...2019-05-24T07:55:06ZMichal Nowikowskiconfig-backend v6: relay parameter in shared-networks is not taken into account for msgs sent from indicated relay agentAs stated in title: when relay param is specified in shared-network and packets are sent from indicated relay agent
they are not matched to this network and its subnet.
It works in all other combinations i.e v4/subnet, v4/network and v6...As stated in title: when relay param is specified in shared-network and packets are sent from indicated relay agent
they are not matched to this network and its subnet.
It works in all other combinations i.e v4/subnet, v4/network and v6/subnet.
It only does not work for v6/network.Kea1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1047AFL-detected hang in named-checkzone2021-10-04T19:25:50ZStephen MorrisAFL-detected hang in named-checkzoneThe attached tarball contains two (corrupt) zone files that cause named-checkzone to hang on perf-c2 (Centos 7.5.1804) and macOS 10.14.5.
[hangs.tar.gz](/uploads/1762cababb23226e184f8dc92b8c86ac/hangs.tar.gz)The attached tarball contains two (corrupt) zone files that cause named-checkzone to hang on perf-c2 (Centos 7.5.1804) and macOS 10.14.5.
[hangs.tar.gz](/uploads/1762cababb23226e184f8dc92b8c86ac/hangs.tar.gz)https://gitlab.isc.org/isc-projects/kea/-/issues/619distcheck failure2019-08-12T09:14:40ZWlodzimierz Wenceldistcheck failureThere is a weird error that caused distcheck to fail, failures like that are showing up from time to time on jenkins, maybe someone came across this and know what is going on
https://jenkins.isc.org/job/kea-master-distcheck/315/executio...There is a weird error that caused distcheck to fail, failures like that are showing up from time to time on jenkins, maybe someone came across this and know what is going on
https://jenkins.isc.org/job/kea-master-distcheck/315/execution/node/99/log/
end of the log:
```
[ RUN ] Dhcp6GetConfigTest/Dhcp6GetConfigTest.run/57
[ OK ] Dhcp6GetConfigTest/Dhcp6GetConfigTest.run/57 (4 ms)
[----------] 58 tests from Dhcp6GetConfigTest/Dhcp6GetConfigTest (181 ms total)
[----------] Global test environment tear-down
[==========] 569 tests from 26 test cases ran. (12178 ms total)
[ PASSED ] 569 tests.
YOU HAVE 2 DISABLED TESTS
PASS: dhcp6_unittests
=============
1 test passed
=============
make[6]: Leaving directory '/home/jenkins/workspace/kea-master-distcheck/kea-1.5.0-git/_build/sub/src/bin/dhcp6/tests'
make[5]: *** [Makefile:1423: check-am] Error 2
make[5]: Leaving directory '/home/jenkins/workspace/kea-master-distcheck/kea-1.5.0-git/_build/sub/src/bin/dhcp6/tests'
make[4]: *** [Makefile:773: check-recursive] Error 1
make[4]: Leaving directory '/home/jenkins/workspace/kea-master-distcheck/kea-1.5.0-git/_build/sub/src/bin/dhcp6'
make[3]: *** [Makefile:440: check-recursive] Error 1
make[3]: Leaving directory '/home/jenkins/workspace/kea-master-distcheck/kea-1.5.0-git/_build/sub/src/bin'
make[2]: *** [Makefile:438: check-recursive] Error 1
make[2]: Leaving directory '/home/jenkins/workspace/kea-master-distcheck/kea-1.5.0-git/_build/sub/src'
make[1]: *** [Makefile:609: check-recursive] Error 1
make[1]: Leaving directory '/home/jenkins/workspace/kea-master-distcheck/kea-1.5.0-git/_build/sub'
make: *** [Makefile:823: distcheck] Error 1
sh: line 1: 28607 Terminated sleep 3
```Kea1.6-finalhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/19HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined2019-11-22T11:13:17ZJoe LeVequeHAVE_SO_BINDTODEVICE referenced before it has a chance to be defined---
name: HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined
---
**Describe the bug**
In includes/osdep.h, `HAVE_SO_BINDTODEVICE` is referenced on [line 152](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includ...---
name: HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined
---
**Describe the bug**
In includes/osdep.h, `HAVE_SO_BINDTODEVICE` is referenced on [line 152](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includes/osdep.h#L152) in the following conditional:
```
#if defined (USE_BPF_SEND) || defined (USE_NIT_SEND) || \
defined (USE_DLPI_SEND) || defined (USE_UPF_SEND) || \
defined (USE_LPF_SEND) || \
(defined (USE_SOCKET_SEND) && defined (HAVE_SO_BINDTODEVICE))
# define USE_SOCKET_FALLBACK
# define USE_FALLBACK
#endif
```
However, it might not get defined until [line 267](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includes/osdep.h#L267), as follows:
```
#if defined (SO_BINDTODEVICE) && !defined (HAVE_SO_BINDTODEVICE)
# define HAVE_SO_BINDTODEVICE
#endif
```
Therefore, if `USE_SOCKET_SEND` is defined, it is possible that `USE_SOCKET_FALLBACK` and `USE_FALLBACK` will not get defined, even though they should, simply because `HAVE_SO_BINDTODEVICE` is referenced before it has had a chance to get defined.
**To Reproduce**
Steps to reproduce the behavior:
1. Add a `#pragma message()` line inside the first `#if` block mentioned above (e.g., at line 153 of includes/osdep.h) so that the preprocessor will print the message if it enters the block
2. Compile isc-dhcp on a system which defines `SO_BINDTODEVICE` (e.g., Debian Stretch), while also defining `USE_SOCKETS` (e.g., via the `--enable-use-sockets` configure flag)
3. Note that the message does not print, although it should
**Expected behavior**
`HAVE_SO_BINDTODEVICE` should have an opportunity to be defined before it is referenced
**Environment:**
- ISC DHCP version: All versions since commit d758ad8cac9c00c70cfe4dd459bf7e87c268c579 (pre-version 4.0.0)
- OS: Debian Jessie/Stretch, most likely many other Linux flavors
- Which features were compiled in: `USE_SOCKETS`
**Describe the solution you'd like**
Reorder the file includes/osdep.h to ensure `HAVE_SO_BINDTODEVICE` has a chance to be defined before it is referenced.4.4.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1045AFL detected crash in named-checkconf2021-10-04T19:25:44ZStephen MorrisAFL detected crash in named-checkconfThe attached tarball contains a number of (corrupt) configuration files that cause a crash of named-checkconf.
All the files crash named-checkconf if built on perf-c2 (Centos 7.5.1804). Only eight of them crash the program when running...The attached tarball contains a number of (corrupt) configuration files that cause a crash of named-checkconf.
All the files crash named-checkconf if built on perf-c2 (Centos 7.5.1804). Only eight of them crash the program when running on macOS 10.14.5.
[results-2019-05-21-1311.tar.gz](/uploads/ff4a43189ab39d470197cd28a474002b/results-2019-05-21-1311.tar.gz)https://gitlab.isc.org/isc-projects/bind9/-/issues/1044gen fails to generate headers on Debian buster2019-05-29T11:34:39ZOndřej Surýgen fails to generate headers on Debian buster`./gen` utility fails to go through all the files it should generating almost empty header files because it's missing the defines from `config.h`.`./gen` utility fails to go through all the files it should generating almost empty header files because it's missing the defines from `config.h`.BIND 9.15.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1043cppcheck-detected code issues2019-10-02T12:27:39ZStephen Morriscppcheck-detected code issuesA number of issues were detected in commit efff347f969cb9cdf8c520d2d393bbf6f61a2dcb on May 21. Those which don't appear to be down to things like cppcheck not noticing that a REQUIRE has already checked for a pointer being non-null are:
...A number of issues were detected in commit efff347f969cb9cdf8c520d2d393bbf6f61a2dcb on May 21. Those which don't appear to be down to things like cppcheck not noticing that a REQUIRE has already checked for a pointer being non-null are:
**lib/irs/win32/resconf.c(35)**
Variable 'keyFound' is assigned a value that is never used.
**lib/isc/tests/mem_test.c(410)**
Variable 'f' is assigned a value that is never used.
**lib/isc/tests/mem_test.c(531)**
Variable 'size' is assigned a value that is never used.
**lib/isc/unix/net.c(399)**
Unused variable: flags.
**lib/isc/win32/app.c(83)**
Unused variable: result.
**lib/isc/win32/app.c(169)**
Variable 'pHandles' is assigned a value that is never used.
**lib/isc/win32/socket.c(2478)**
Unused variable: result.
**lib/samples/nsprobe.c(110-115)**
A number of fields in the lcl_stat structure have the same name as the query_result_t enum constants and cppcheck complains that "Variable 'XXX' hides enumerator with same name".
The full cppcheck output can be found on Jenkins [here](https://jenkins.isc.org/view/BIND/job/bind9-cpp-check/409/cppcheckResult).October 2019 (9.11.12, 9.14.7, 9.15.5)https://gitlab.isc.org/isc-projects/dhcp/-/issues/18Bundle BIND9 version-correct tar ball into the main repo2019-11-18T15:24:12ZThomas MarkwalderBundle BIND9 version-correct tar ball into the main repoThe BIND9 tarball, Makefile.in and version file were added dhcp/bind directory on the migration-assistant branch. This makes it possible to pull everything needed in just our repo and ensures you have correct version of bind9. It elimi...The BIND9 tarball, Makefile.in and version file were added dhcp/bind directory on the migration-assistant branch. This makes it possible to pull everything needed in just our repo and ensures you have correct version of bind9. It eliminates outsiders needing to run util/bind.sh. We need to follow suit and do this to main repo. Either that or we simply merge the migration-assistant branch into master.4.4.2https://gitlab.isc.org/isc-projects/kea/-/issues/618Address doxygen warnings / errors2019-05-27T08:17:43ZWlodzimierz WencelAddress doxygen warnings / errorsit would be cool to address, before release, some doxygen warnings / errors we currently have
https://jenkins.isc.org/job/Kea_doc/1645/warnings16Result/it would be cool to address, before release, some doxygen warnings / errors we currently have
https://jenkins.isc.org/job/Kea_doc/1645/warnings16Result/Kea1.6Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/617bumping up lib versions before beta release2019-05-27T18:51:35ZWlodzimierz Wencelbumping up lib versions before beta releaseAs always.. we need bumping up lib versions before kea 1.6.0-betaAs always.. we need bumping up lib versions before kea 1.6.0-betaKea1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1042"unable to set effective uid to 0" is a warning, should be fatal (or handled ...2020-06-08T13:03:24ZTimothe Litt"unable to set effective uid to 0" is a warning, should be fatal (or handled better)The story (it's a bit long):
Updated BIND from 9.11.2 to 9.14.1. Basic name resolution works. But some time after startup, nothing appears in log files, and slaves see various zone transfer errors. This appears to be due to failure t...The story (it's a bit long):
Updated BIND from 9.11.2 to 9.14.1. Basic name resolution works. But some time after startup, nothing appears in log files, and slaves see various zone transfer errors. This appears to be due to failure to regain privileges.
The last error logged in syslog was:
````
view external: transfer of 'redacted.net/IN': send: socket is not connected
````
The last message logged in `named`'s log was (4 hours after the syslog message):
````
xfer-out: info: client @0x9f38080 redacted#39072 (redacted.net): view external: transfer of 'redacted.net/IN': AXFR ended: 1 messages, 145 records, 15078 bytes, 0.002 secs (7539000 bytes/sec)
````
About 11 hours after that, the slaves started reporting:
````
error: transfer of 'redacted.net/IN/internal' from redacted#53: failed while receiving responses: connection reset
````
On this machine, `named` is started as `root` and run `-u named`
Looking in the log file, just after setting up the listening sockets we see:
````
unable to set effective uid to 0: Operation not permitted
````
This is repeated after `generating session key for dynamic DNS`
Yet named continued to initialize without further complaint.
Going back to the build, `configure` found support for capabilities, so built `--enable-linux-caps`. But for some reason (which I haven't tracked down), things go astray at runtime. There are no obvious clues - presumably because logging failed. (My guess is that during log rotation, the old log was closed, and a new one could not be opened due to lack of privilege. But that's just a guess. And it doesn't explain why the zone transfers were aborted.)
I noticed that the test in `configure` is merely that a program that calls `cap_set_proc()` (with no arguments) links. I guess that's the best you can do, considering that `configure` should be run without privs, and you have to deal with cross-builds...
One slave, on a different architecture and kernel, also reports the `unable to set effective uid` error, but continued to log (including the failed transfers).
My (external) secondary DNS service runs on NSD, and also reported zone transfer failures. So they are definitely caused by the BIND master.
Building `9.14.2` with `--disable-linux-caps` resolves the symptoms. Tracking down why might be a project for another time.
Recommendations:
- It seems to me that if `named` is built with `--enable-linux-caps`, failure to set effective (uid,gid) to the real or saved uid/gid should be fatal.
It isn't obvious that there are production cases where `named` should be able to survive this - if code is asking for privilege, it should always be because that privilege is required. If it's asking for privilege in cases where it *might* require privilege, the actual operation should fail. But it appears that being unable to log prevented this from being visible, and `named` soldiered on in silence, resolving ordinary requests (hence, triggering no alarms) and failing zone transfers - which eventually got my attention.
Possible cases where continuing might be viable include in testing or debugging, where you specify a non-privileged `-p` port. I'm not sure what the right answer is: two possibilities:
1. Make the `unable to set effective uid` message more prominent
1. Add a command-line switch to make the error a warning (perhaps `-P` -- "ignore failure to obtain privilege")
- Identifying and debugging this would be much simpler if **named ensured that all errors are logged by changing logging such that a file isn't closed until its successor is open** (assuming my guess is correct). This would guarantee that a failure to open gets logged in the previous logfile, which could continue to log. I have verified that the current logging code closes files before opening a successor... Do you want a separate issue for this observation?May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1041crash in 9.14.2, possibly on shutdown, cannot reproduce2020-10-02T08:37:23ZCarl Byingtoncrash in 9.14.2, possibly on shutdown, cannot reproduceUpdating from 9.14.1 to 9.14.2, scripts here do a few shutdown/restarts of bind. I cannot reproduce this.
```
(gdb) bt
#0 0x0000003a210324f5 in raise () from /lib64/libc.so.6
#1 0x0000003a21033cd5 in abort () from /lib64/libc.so.6
#2 ...Updating from 9.14.1 to 9.14.2, scripts here do a few shutdown/restarts of bind. I cannot reproduce this.
```
(gdb) bt
#0 0x0000003a210324f5 in raise () from /lib64/libc.so.6
#1 0x0000003a21033cd5 in abort () from /lib64/libc.so.6
#2 0x000000000041e483 in assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>,
cond=<value optimized out>) at ./main.c:253
#3 0x00007f8acaa1b23a in isc_assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>,
cond=<value optimized out>) at assertions.c:50
#4 0x00007f8acaa2da9b in isc_mempool_destroy (mpctxp=0x7f8abc6c4e20) at mem.c:1647
#5 0x00007f8abc3adb59 in plugin_destroy (instp=0x7f8ac40c3e30) at filter-aaaa.c:456
#6 0x00007f8acb6df4b2 in unload_plugin (pluginp=<value optimized out>) at hooks.c:238
#7 0x00007f8acb6df5ca in ns_plugins_free (mctx=0x211d210, listp=<value optimized out>) at hooks.c:553
#8 0x00007f8acb406465 in destroy (view=0x7f8ac01872e0) at view.c:559
#9 0x00007f8acb42086e in zone_free (zone=0x7f8ac0b66d70) at zone.c:1135
#10 0x00007f8acb429d90 in zone_shutdown (task=<value optimized out>, event=<value optimized out>) at zone.c:13311
#11 0x00007f8acaa3b8b7 in dispatch (queuep=<value optimized out>) at task.c:1130
#12 run (queuep=<value optimized out>) at task.c:1297
#13 0x0000003a21407aa1 in start_thread () from /lib64/libpthread.so.0
#14 0x0000003a210e8c4d in clone () from /lib64/libc.so.6
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/kea/-/issues/616error msgs contain references to config file while config-backend is used2019-07-22T10:49:20ZMichal Nowikowskierror msgs contain references to config file while config-backend is usedI got an error message:
```Config reload failed:configuration error using file '/usr/local/etc/kea/kea.conf': a pool of type V4, with the following address range: 192.168.50.1-192.168.50.100...```
while this config file did not contain ...I got an error message:
```Config reload failed:configuration error using file '/usr/local/etc/kea/kea.conf': a pool of type V4, with the following address range: 192.168.50.1-192.168.50.100...```
while this config file did not contain any subnet definitions - subnets were defined over config-backend.
Error messages should not refer to config file if config is stored in config-backend.Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/17Log messages always additionally print to console, even in release builds2020-02-13T13:43:02ZJoe LeVequeLog messages always additionally print to console, even in release builds---
name: Log messages always additionally print to console, even in release builds
---
**Describe the bug**
Lines [40-44 of omapip/errwarn.c](https://gitlab.isc.org/isc-projects/dhcp/blob/master/omapip/errwarn.c#L40) define `log_per...---
name: Log messages always additionally print to console, even in release builds
---
**Describe the bug**
Lines [40-44 of omapip/errwarn.c](https://gitlab.isc.org/isc-projects/dhcp/blob/master/omapip/errwarn.c#L40) define `log_perror` differently based on whether or not it is a DEBUG build. This is done in order to print all log messages to stderr in addition to logging them to syslog *if* compiled with `DEBUG` defined.
However, the definitions are currently as follows:
```
#ifdef DEBUG
int log_perror = -1;
#else
int log_perror = 1;
#endif
```
Therefore, `log_perror` is **always** nonzero no matter whether `DEBUG` is defined or not, thus **always** causing all log_*() functions to print log messages to stderr in addition to logging them to syslog.
For our application, we are redirecting output from stderr to syslog, and we have a very noisy log because we are seeing all log messages at INFO level and above twice as well as all DEBUG-level messages show up in our syslogs, even though DEBUG-level messages are disabled in release builds.
Please let me know if you have any questions.
**To Reproduce**
1. Compile dhcp in non-DEBUG mode (i.e., don't define `DEBUG`)
2. Run a DHCP program (e.g., dhcrelay) in non-daemon mode (or run in daemon mode but make sure to have a facility to redirect stderr to somewhere visible, like syslog)
3. Notice that all log_*() functions are also echoed to stderr, although they should not be
**Expected behavior**
If compiled without defining `DEBUG`, log messages should *not* also get output to stderr
**Environment:**
- ISC DHCP version: All releases (it appears this bug has existed since 1/26/2000)
- OS: All
**Additional Information**
I originally submitted this bug via your old bug reporting system as "ISC-Bugs #47288" on 3/8/2018. It appears that system was deprecated soon thereafter?
**Describe the solution you'd like**
A quick and simple fix is below:
```
#ifdef DEBUG
int log_perror = 1;
#else
int log_perror = 0;
#endif
```Outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1038Make proper use of the atomics2019-07-23T12:30:59ZWitold KrecickiMake proper use of the atomicsuse isc_refcount_t everywhere, use atomic_ functions where dealing with atomic variablesuse isc_refcount_t everywhere, use atomic_ functions where dealing with atomic variablesWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1037Follow-up from "Make isc_app_t opaque and thread-safe"2021-10-04T19:24:49ZOndřej SurýFollow-up from "Make isc_app_t opaque and thread-safe"The following discussion from !1936 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1936#note_57874): (+2 comments)
> why is this needed anymore? There ctx for it ...The following discussion from !1936 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1936#note_57874): (+2 comments)
> why is this needed anymore? There ctx for it to be in.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1036Follow-up from "Make isc_app_t opaque and thread-safe"2021-10-04T19:24:38ZOndřej SurýFollow-up from "Make isc_app_t opaque and thread-safe"The following discussion from !1936 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1936#note_57873):
> Why is this needed anymore?The following discussion from !1936 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1936#note_57873):
> Why is this needed anymore?