RE: Bind 9.16.1 crash on Ubuntu
Hi Robie (and Marc), I've never reported a bug to Ubuntu before. I ran ubuntu-bug against the crash report and told it to send the report. It appears to have uploaded it to the Ubuntu error tracker (https://errors.ubuntu.com/user/1be5ee847bb6c14eae7458cbbda7ac91a5fd65d5d01f3f9d3dbc4480e44712035ed9c455e3cf04ec7eeadf72dd7f5414771cff9ba752940658ff902749b175e9), but I don't know how to verify that it sent what it was supposed to send. Please let me know if there's anything else I need to do. Thanks, Ben -Original Message- From: Ben Bridges Sent: Thursday, December 8, 2022 5:57 PM To: Robie Basak Cc: ubuntu-devel-discuss@lists.ubuntu.com Subject: RE: Bind 9.16.1 crash on Ubuntu Hi Robie, I really appreciate the information. I totally understand your (Ubuntu developers) position on these sorts of matters. We've been using Ubuntu for at least 10 years now and have never had any issues with it until this BIND assertion failure occurred. It's been a good platform for us. Unfortunately, when it comes to BIND, it leaves the users in a bit of a precarious position. If you run the bind9 package, you incur the ire of ISC and the members of the BIND users forum (who chastise you for "running such an old version of BIND" and just tell you to upgrade BIND) if you post issues there. If you use the ISC packages in their PPA repository, you can't get any (or only limited) assistance from the Ubuntu developers. As popular as BIND is, it seems like it would be one of the packages that you would want to update regularly from the upstream minor version releases. But perhaps BIND isn't run on Ubuntu as much as I think it might be. Anyway, I'll try to file a bug report, but apport failed to create a core dump (file size too large), and I suspect you won't be able to do much without it. Thanks again for the information. Ben -Original Message- From: Robie Basak Sent: Thursday, December 8, 2022 2:06 PM To: Ben Bridges Cc: ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Bind 9.16.1 crash on Ubuntu Hi, On Thu, Dec 08, 2022 at 05:22:34PM +, Ben Bridges wrote: > This is bind9 1:9.16.1-0ubuntu2.11 running on Ubuntu 20.04.5 LTS (fully > patched). Has this issue been seen before? If so, has it been fixed, or is > it being fixed? Is this the right forum for this posting? This is the right place to ask, but for specific bugs, as Marc said please make sure a bug exists against the package in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/bind9 to check existing reports, and "Report a bug" in the top right if you need to file a new report. > More generally ... to what extent do you update the Ubuntu bind9 package? Is > it literally the 9.16.1 base source code (in focal) with no updates other > than to patch the CVE security vulnerabilities? Or are there other patches > in it as well? It varies - we'll patch as we think is appropriate, though that has a maintenance burden so we try to keep the patching minimal. You can see the full set of patches currently applied against the Ubuntu 20.04 bind9 package here (the `series` file defines what is applied, as opposed to simply the contents of the directory): https://git.launchpad.net/ubuntu/+source/bind9/tree/debian/patches?h=ubuntu/focal-devel Of course the outcome also depends on how the package is built. You can see that here: https://git.launchpad.net/ubuntu/+source/bind9/tree/debian/rules?h=ubuntu/focal-devel > For a given Ubuntu LTS version (such as focal), do you ever "start over" > with the newest minor release of that branch of BIND (9.16 for focal, 9.18 > for jammy)? Or do you just continue patching the initial release of the > branch? It depends. We'll update to the latest upstream point release on a case-by-case basis. Upstreams vary in policy and the quality of what they'll stick in there, and we don't want to regress our users, or change behaviour on them! Formally, our policy on what is acceptable to update like this is here: https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases And then for an update like this to actually happen, an Ubuntu developer needs to drive it. The Server Team does update some packages routinely, but it doesn't look like bind9 is currently in that list. > Is there a specific version of 9.16 that you can say 1:9.16.1-0ubuntu2.11 is > equivalent to in terms of patches (both security and non-security)? No - you have to study the patches. > Do you recommend for or against Ubuntu users using the BIND packages in ISC's > PPA repository instead of the bind9 package in the Ubuntu repository? You can of course do what you like on your own system. But Ubuntu can only reasonably support what it ships, so using only our packages is our recommendation. If we get a bug report about a problem caused by a third party package, then we normally have to reject that report since there's nothing we can do about that third party package! Most packaging problems our users
Re: Bind 9.16.1 crash on Ubuntu
Hi Ben, On Thu, Dec 08, 2022 at 11:56:48PM +, Ben Bridges wrote: > Unfortunately, when it comes to BIND, it leaves the users in a bit of a > precarious position. If you run the bind9 package, you incur the ire of ISC > and the members of the BIND users forum (who chastise you for "running such > an old version of BIND" and just tell you to upgrade BIND) if you post issues > there. If you use the ISC packages in their PPA repository, you can't get > any (or only limited) assistance from the Ubuntu developers. As popular as > BIND is, it seems like it would be one of the packages that you would want to > update regularly from the upstream minor version releases. But perhaps BIND > isn't run on Ubuntu as much as I think it might be. > > Anyway, I'll try to file a bug report, but apport failed to create a core > dump (file size too large), and I suspect you won't be able to do much > without it. It's often possible to look at it from the other end. If they've fixed the problem in a point release, then we can look at their upstream commits, find the relevant one, and cherry-pick it. Robie signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
RE: Bind 9.16.1 crash on Ubuntu
Hi Robie, I really appreciate the information. I totally understand your (Ubuntu developers) position on these sorts of matters. We've been using Ubuntu for at least 10 years now and have never had any issues with it until this BIND assertion failure occurred. It's been a good platform for us. Unfortunately, when it comes to BIND, it leaves the users in a bit of a precarious position. If you run the bind9 package, you incur the ire of ISC and the members of the BIND users forum (who chastise you for "running such an old version of BIND" and just tell you to upgrade BIND) if you post issues there. If you use the ISC packages in their PPA repository, you can't get any (or only limited) assistance from the Ubuntu developers. As popular as BIND is, it seems like it would be one of the packages that you would want to update regularly from the upstream minor version releases. But perhaps BIND isn't run on Ubuntu as much as I think it might be. Anyway, I'll try to file a bug report, but apport failed to create a core dump (file size too large), and I suspect you won't be able to do much without it. Thanks again for the information. Ben -Original Message- From: Robie Basak Sent: Thursday, December 8, 2022 2:06 PM To: Ben Bridges Cc: ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Bind 9.16.1 crash on Ubuntu Hi, On Thu, Dec 08, 2022 at 05:22:34PM +, Ben Bridges wrote: > This is bind9 1:9.16.1-0ubuntu2.11 running on Ubuntu 20.04.5 LTS (fully > patched). Has this issue been seen before? If so, has it been fixed, or is > it being fixed? Is this the right forum for this posting? This is the right place to ask, but for specific bugs, as Marc said please make sure a bug exists against the package in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/bind9 to check existing reports, and "Report a bug" in the top right if you need to file a new report. > More generally ... to what extent do you update the Ubuntu bind9 package? Is > it literally the 9.16.1 base source code (in focal) with no updates other > than to patch the CVE security vulnerabilities? Or are there other patches > in it as well? It varies - we'll patch as we think is appropriate, though that has a maintenance burden so we try to keep the patching minimal. You can see the full set of patches currently applied against the Ubuntu 20.04 bind9 package here (the `series` file defines what is applied, as opposed to simply the contents of the directory): https://git.launchpad.net/ubuntu/+source/bind9/tree/debian/patches?h=ubuntu/focal-devel Of course the outcome also depends on how the package is built. You can see that here: https://git.launchpad.net/ubuntu/+source/bind9/tree/debian/rules?h=ubuntu/focal-devel > For a given Ubuntu LTS version (such as focal), do you ever "start over" > with the newest minor release of that branch of BIND (9.16 for focal, 9.18 > for jammy)? Or do you just continue patching the initial release of the > branch? It depends. We'll update to the latest upstream point release on a case-by-case basis. Upstreams vary in policy and the quality of what they'll stick in there, and we don't want to regress our users, or change behaviour on them! Formally, our policy on what is acceptable to update like this is here: https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases And then for an update like this to actually happen, an Ubuntu developer needs to drive it. The Server Team does update some packages routinely, but it doesn't look like bind9 is currently in that list. > Is there a specific version of 9.16 that you can say 1:9.16.1-0ubuntu2.11 is > equivalent to in terms of patches (both security and non-security)? No - you have to study the patches. > Do you recommend for or against Ubuntu users using the BIND packages in ISC's > PPA repository instead of the bind9 package in the Ubuntu repository? You can of course do what you like on your own system. But Ubuntu can only reasonably support what it ships, so using only our packages is our recommendation. If we get a bug report about a problem caused by a third party package, then we normally have to reject that report since there's nothing we can do about that third party package! Most packaging problems our users report are caused by third party repositories breaking things, especially on future release upgrades. Fundamentally there are some breakages that even a perfect third party repository maintainer cannot avoid. The apt/dpkg system wasn't designed to work this way, even if this kind of use is really common in practice. People tend to get away with it because our policy on changing as little as possible in stable releases means that these issues don't show themselves. Until they try to upgrade to the new release, things explode and they blame us :-( So while I don't think it's Ubuntu's official position or anything, I would avoid using third party repositories as much as possible. On the other h
ntfs-3g app deadlock bug report
Hi I find live lock bug in ntfs-3g app. I post it but not respond from its public repos. so I report it this mailing list the bug I found is written below. [Environment] 22.04 5.15.0-43-generic ubuntu kernel. ntfs-3g version ntfs-3g 2021.8.22 integrated FUSE 28 - Third Generation NTFS Driver [Problem] I bumped on livelock and analyze it. and concluded that it is needed to be fixed. it happens when 3 operation concurrently progressing. usb detach by user. and kernel detect it. mount.ntfs umount request & device release operation pool-udisksd umount operation. [Conclusion] mounted target device file must be released after /dev/fuse release. it makes deadlocky scenario. fuse file system "fuse_simple_request" should not be waiting forever. it is hard to solve this situation by interrupting application. huntask panic configuration make user kernel panic. user don't know why. [Analysis] I got a kernel crash dump file. and analyze it. here is the scenario description. kworker detect usb is detached from computer. it is blocked by umount operation (pool-udiskd) PID: 8 TASK: 88810029e400 CPU: 0 COMMAND: "kworker/0:1" 0 [c906f6f0] __schedule at 81d57c0d 1 [c906f778] schedule at 81d57fae 2 [c906f798] rwsem_down_read_slowpath at 81d5a2de 3 [c906f830] down_read at 81d5a373 // wait s_umount 4 [c906f848] get_super at 813799ca 5 [c906f878] fsync_bdev at 815c6f46 6 [c906f8a0] delete_partition at 815e9328 7 [c906f8c0] blk_drop_partitions at 815e9b3e 8 [c906f8e8] del_gendisk at 815e75f1 // lock mutex 9 [c906f930] sd_remove at 818cd325 10 [c906f958] __device_release_driver at 8184006f 11 [c906f990] device_release_driver at 818400a9 12 [c906f9b0] bus_remove_device at 8183f28e 13 [c906f9d8] device_del at 818399ac 14 [c906fa28] __scsi_remove_device at 818c2628 15 [c906fa50] scsi_forget_host at 818c029f 16 [c906fa70] scsi_remove_host at 818b3727 17 [c906fa98] usb_stor_disconnect at c0659b20 [usb_storage] 18 [c906fac0] usb_unbind_interface at 8194ef30 19 [c906fb18] __device_release_driver at 8184006f 20 [c906fb50] device_release_driver at 818400a9 21 [c906fb70] bus_remove_device at 8183f28e 22 [c906fb98] device_del at 818399ac 23 [c906fbe8] usb_disable_device at 8194cdce 24 [c906fc30] usb_disconnect.cold at 81d19e09 25 [c906fc80] hub_port_connect at 81944bb8 26 [c906fd00] hub_port_connect_change at 819454b1 27 [c906fd70] port_event at 81945d77 28 [c906fe08] hub_event at 819460a7 29 [c906fe78] process_one_work at 810d9e7b 30 [c906fec8] worker_thread at 810da073 31 [c906ff10] kthread at 810e1cba 32 [c906ff50] ret_from_fork at 81004bc2 3 [c906f830] down_read at 81d5a373 c906f838: [888154d36800:kmalloc-2k] c906f870 c906f848: get_super+154 it request umount. and release /dev/sdc file before release /dev/fuse. but. it is blocked by usb detach. PID: 18681 TASK: 88810e5b8000 CPU: 1 COMMAND: "mount.ntfs" 0 [c9ea7c50] __schedule at 81d57c0d 1 [c9ea7cd8] schedule at 81d57fae 2 [c9ea7cf8] schedule_preempt_disabled at 81d5839e 3 [c9ea7d08] __mutex_lock.constprop.0 at 81d59053 4 [c9ea7d80] __mutex_lock_slowpath at 81d59353 5 [c9ea7d90] mutex_lock at 81d59394 // wait open mutex 6 [c9ea7da8] blkdev_put at 815c765a 7 [c9ea7de0] blkdev_close at 815c86e7 8 [c9ea7df8] __fput at 8137704f 9 [c9ea7e30] fput at 8137724e 10 [c9ea7e40] task_work_run at 810deb6d 11 [c9ea7e68] exit_to_user_mode_loop at 81160fc0 12 [c9ea7e90] exit_to_user_mode_prepare at 8116106c 13 [c9ea7ea8] syscall_exit_to_user_mode at 81d4f327 14 [c9ea7ec0] do_syscall_64 at 81d4b1b9 15 [c9ea7ef8] exit_to_user_mode_prepare at 81161007 16 [c9ea7f10] syscall_exit_to_user_mode at 81d4f327 17 [c9ea7f28] do_syscall_64 at 81d4b1b9 RIP: 7f3e315fb117 RSP: 7fff16bcb628 RFLAGS: 0246 RAX: RBX: 55cc1b45c710 RCX: 7f3e315fb117 RDX: RSI: 0006 RDI: 0003 RBP: 55cc1b45c970 R8: 55cc1b476940 R9: R10: 0005 R11: 0246 R12: 7f3e314e36c0 R13: 55cc1b45c710 R14: 55cc1b467030 R15: ORIG_RAX: 0003 CS: 0033 SS: 002b 3 [c9ea7d08] __mutex_lock.constprop.0 at 81d59053 ff
Re: Bind 9.16.1 crash on Ubuntu
Hi, On Thu, Dec 08, 2022 at 05:22:34PM +, Ben Bridges wrote: > This is bind9 1:9.16.1-0ubuntu2.11 running on Ubuntu 20.04.5 LTS (fully > patched). Has this issue been seen before? If so, has it been fixed, or is > it being fixed? Is this the right forum for this posting? This is the right place to ask, but for specific bugs, as Marc said please make sure a bug exists against the package in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/bind9 to check existing reports, and "Report a bug" in the top right if you need to file a new report. > More generally ... to what extent do you update the Ubuntu bind9 package? Is > it literally the 9.16.1 base source code (in focal) with no updates other > than to patch the CVE security vulnerabilities? Or are there other patches > in it as well? It varies - we'll patch as we think is appropriate, though that has a maintenance burden so we try to keep the patching minimal. You can see the full set of patches currently applied against the Ubuntu 20.04 bind9 package here (the `series` file defines what is applied, as opposed to simply the contents of the directory): https://git.launchpad.net/ubuntu/+source/bind9/tree/debian/patches?h=ubuntu/focal-devel Of course the outcome also depends on how the package is built. You can see that here: https://git.launchpad.net/ubuntu/+source/bind9/tree/debian/rules?h=ubuntu/focal-devel > For a given Ubuntu LTS version (such as focal), do you ever "start over" > with the newest minor release of that branch of BIND (9.16 for focal, 9.18 > for jammy)? Or do you just continue patching the initial release of the > branch? It depends. We'll update to the latest upstream point release on a case-by-case basis. Upstreams vary in policy and the quality of what they'll stick in there, and we don't want to regress our users, or change behaviour on them! Formally, our policy on what is acceptable to update like this is here: https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases And then for an update like this to actually happen, an Ubuntu developer needs to drive it. The Server Team does update some packages routinely, but it doesn't look like bind9 is currently in that list. > Is there a specific version of 9.16 that you can say 1:9.16.1-0ubuntu2.11 is > equivalent to in terms of patches (both security and non-security)? No - you have to study the patches. > Do you recommend for or against Ubuntu users using the BIND packages in ISC's > PPA repository instead of the bind9 package in the Ubuntu repository? You can of course do what you like on your own system. But Ubuntu can only reasonably support what it ships, so using only our packages is our recommendation. If we get a bug report about a problem caused by a third party package, then we normally have to reject that report since there's nothing we can do about that third party package! Most packaging problems our users report are caused by third party repositories breaking things, especially on future release upgrades. Fundamentally there are some breakages that even a perfect third party repository maintainer cannot avoid. The apt/dpkg system wasn't designed to work this way, even if this kind of use is really common in practice. People tend to get away with it because our policy on changing as little as possible in stable releases means that these issues don't show themselves. Until they try to upgrade to the new release, things explode and they blame us :-( So while I don't think it's Ubuntu's official position or anything, I would avoid using third party repositories as much as possible. On the other hand, we *do* maintain our own packages, and if there's an issue, it's our intention to patch it if that's possible and reasonable against our stable release policies that apply across all of our packages[1]. So please do make sure that a bug report exists :) Robie [1] https://wiki.ubuntu.com/StableReleaseUpdates signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Bind 9.16.1 crash on Ubuntu
On Thu, Dec 8, 2022 at 12:23 PM Ben Bridges wrote:
> Greetings.
>
>
>
> Yesterday morning one of our BIND daemons crashed. The following messages
> were logged in named.run at the time:
>
>
>
> 07-Dec-2022 11:58:37.097 general: critical: netmgr.c:687:
> REQUIRE((__builtin_expect(!!((sock) != ((void *)0)), 1) &&
> __builtin_expect(!!(((const isc__magic_t *)(sock))->magic == ((('N') << 24
> | ('M') << 16 | ('S') << 8 | ('K', 1))) failed, back trace
>
> It looks like it could be
https://gitlab.isc.org/isc-projects/bind9/-/issues/3483 .
Jeff
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Bind 9.16.1 crash on Ubuntu
Hi,
On 2022-12-08 12:22, Ben Bridges wrote:
Greetings.
Yesterday morning one of our BIND daemons crashed. The following messages were
logged in named.run at the time:
07-Dec-2022 11:58:37.097 general: critical: netmgr.c:687:
REQUIRE((__builtin_expect(!!((sock) != ((void *)0)), 1) &&
__builtin_expect(!!(((const isc__magic_t *)(sock))->magic == ((('N') << 24 |
('M') << 16 | ('S') << 8 | ('K', 1))) failed, back trace
07-Dec-2022 11:58:37.097 general: critical: #0 0x56508c798e43 in ??
07-Dec-2022 11:58:37.097 general: critical: #1 0x7fa72e881ac0 in ??
07-Dec-2022 11:58:37.097 general: critical: #2 0x7fa72e89978a in ??
07-Dec-2022 11:58:37.097 general: critical: #3 0x7fa72e89a240 in ??
07-Dec-2022 11:58:37.097 general: critical: #4 0x7fa72e89e18b in ??
07-Dec-2022 11:58:37.097 general: critical: #5 0x7fa72eb67707 in ??
07-Dec-2022 11:58:37.097 general: critical: #6 0x7fa72eb68fe9 in ??
07-Dec-2022 11:58:37.097 general: critical: #7 0x7fa72eb779b0 in ??
07-Dec-2022 11:58:37.097 general: critical: #8 0x7fa72eb7f9a7 in ??
07-Dec-2022 11:58:37.097 general: critical: #9 0x7fa72eb8116e in ??
07-Dec-2022 11:58:37.097 general: critical: #10 0x7fa72eb816cd in ??
07-Dec-2022 11:58:37.097 general: critical: #11 0x7fa72eb823c9 in ??
07-Dec-2022 11:58:37.097 general: critical: #12 0x7fa72eb884c6 in ??
07-Dec-2022 11:58:37.097 general: critical: #13 0x7fa72e8a8fa1 in ??
07-Dec-2022 11:58:37.097 general: critical: #14 0x7fa72e370609 in ??
07-Dec-2022 11:58:37.097 general: critical: #15 0x7fa72e28f133 in ??
07-Dec-2022 11:58:37.097 general: critical: exiting (due to assertion failure)
This is bind9 1:9.16.1-0ubuntu2.11 running on Ubuntu 20.04.5 LTS (fully
patched). Has this issue been seen before? If so, has it been fixed, or is it
being fixed? Is this the right forum for this posting?
More generally … to what extent do you update the Ubuntu bind9 package? Is it
literally the 9.16.1 base source code (in focal) with no updates other than to
patch the CVE security vulnerabilities? Or are there other patches in it as
well? For a given Ubuntu LTS version (such as focal), do you ever “start over”
with the newest minor release of that branch of BIND (9.16 for focal, 9.18 for
jammy)? Or do you just continue patching the initial release of the branch? Is
there a specific version of 9.16 that you can say 1:9.16.1-0ubuntu2.11 is
equivalent to in terms of patches (both security and non-security)? Do you
recommend for or against Ubuntu users using the BIND packages in ISC’s PPA
repository instead of the bind9 package in the Ubuntu repository?
Thanks,
Ben Bridges
City Utilities
SpringNet
Sales 417.575.7000 | Support 417.874.8000 | springnet.net
Please file a bug against bind9. It looks like that crash is related to this
bug:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1981
which ultimately was fixed by this merge request:
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3721/commits
Thanks,
Marc.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Bind 9.16.1 crash on Ubuntu
Greetings.
Yesterday morning one of our BIND daemons crashed. The following messages were
logged in named.run at the time:
07-Dec-2022 11:58:37.097 general: critical: netmgr.c:687:
REQUIRE((__builtin_expect(!!((sock) != ((void *)0)), 1) &&
__builtin_expect(!!(((const isc__magic_t *)(sock))->magic == ((('N') << 24 |
('M') << 16 | ('S') << 8 | ('K', 1))) failed, back trace
07-Dec-2022 11:58:37.097 general: critical: #0 0x56508c798e43 in ??
07-Dec-2022 11:58:37.097 general: critical: #1 0x7fa72e881ac0 in ??
07-Dec-2022 11:58:37.097 general: critical: #2 0x7fa72e89978a in ??
07-Dec-2022 11:58:37.097 general: critical: #3 0x7fa72e89a240 in ??
07-Dec-2022 11:58:37.097 general: critical: #4 0x7fa72e89e18b in ??
07-Dec-2022 11:58:37.097 general: critical: #5 0x7fa72eb67707 in ??
07-Dec-2022 11:58:37.097 general: critical: #6 0x7fa72eb68fe9 in ??
07-Dec-2022 11:58:37.097 general: critical: #7 0x7fa72eb779b0 in ??
07-Dec-2022 11:58:37.097 general: critical: #8 0x7fa72eb7f9a7 in ??
07-Dec-2022 11:58:37.097 general: critical: #9 0x7fa72eb8116e in ??
07-Dec-2022 11:58:37.097 general: critical: #10 0x7fa72eb816cd in ??
07-Dec-2022 11:58:37.097 general: critical: #11 0x7fa72eb823c9 in ??
07-Dec-2022 11:58:37.097 general: critical: #12 0x7fa72eb884c6 in ??
07-Dec-2022 11:58:37.097 general: critical: #13 0x7fa72e8a8fa1 in ??
07-Dec-2022 11:58:37.097 general: critical: #14 0x7fa72e370609 in ??
07-Dec-2022 11:58:37.097 general: critical: #15 0x7fa72e28f133 in ??
07-Dec-2022 11:58:37.097 general: critical: exiting (due to assertion failure)
This is bind9 1:9.16.1-0ubuntu2.11 running on Ubuntu 20.04.5 LTS (fully
patched). Has this issue been seen before? If so, has it been fixed, or is it
being fixed? Is this the right forum for this posting?
More generally ... to what extent do you update the Ubuntu bind9 package? Is
it literally the 9.16.1 base source code (in focal) with no updates other than
to patch the CVE security vulnerabilities? Or are there other patches in it as
well? For a given Ubuntu LTS version (such as focal), do you ever "start over"
with the newest minor release of that branch of BIND (9.16 for focal, 9.18 for
jammy)? Or do you just continue patching the initial release of the branch?
Is there a specific version of 9.16 that you can say 1:9.16.1-0ubuntu2.11 is
equivalent to in terms of patches (both security and non-security)? Do you
recommend for or against Ubuntu users using the BIND packages in ISC's PPA
repository instead of the bind9 package in the Ubuntu repository?
Thanks,
Ben Bridges
[City Utilities]
[SpringNet]
Sales 417.575.7000 | Support 417.874.8000 |
springnet.net
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
