"options MAXMEMDOM=2" vs. amd64 DBG kernel booting: 3000+ "kernel: Process (pid 1) got signal 5" notices during booting
While my kernel/world build procedures build both DBG and NODBG kernels and worlds, I normally run the NODBG kernel and world, using DBG only when I need to for problem investigation. I recently had reason to use the DBG kernel and found it got the oddity of 3000+ instances of "kernel: Process (pid 1) got signal 5" during booting, as reported in /var/log/messages . An example is: . . . Nov 20 23:13:09 7950X3D-UFS shutdown[20174]: reboot by root: Nov 20 23:13:09 7950X3D-UFS syslogd: exiting on signal 15 Nov 20 23:14:21 7950X3D-UFS syslogd: kernel boot file is /boot/kernel/kernel Nov 20 23:14:21 7950X3D-UFS kernel: got signal 5 Nov 20 23:14:21 7950X3D-UFS kernel: Process (pid 1) got signal 5 Nov 20 23:14:21 7950X3D-UFS syslogd: last message repeated 3133 times Nov 20 23:14:21 7950X3D-UFS kernel: intsmb0: at device 20.0 on pci0 . . . This stopped when I commented out the: optionsMAXMEMDOM=2 that I've had historically and built, installed, and booted the resulting DBG kernel. I'll note that I never had the messages for the NODDBG kernel, despite it also having that line. For reference: # uname -apKU FreeBSD 7950X3D-UFS 15.0-CURRENT FreeBSD 15.0-CURRENT #2 main-n266130-d521abdff236-dirty: Tue Nov 21 21:03:11 PST 2023 root@7950X3D-UFS:/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG amd64 amd64 152 152 # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ d521abdff236 (HEAD -> main, freebsd/main, freebsd/HEAD) Update ASLR stack sysctl description in security.7 and mitigations.7 Author: Ed Maste Commit: Ed Maste CommitDate: 2023-10-24 22:29:25 + branch: main merge-base: d521abdff2367a5c72a773a815fc3d99403274f5 merge-base: CommitDate: 2023-10-24 22:29:25 + n266130 (--first-parent --count for merge-base) === Mark Millard marklmi at yahoo.com
Re: bl[ao]cklistd, some first impressions...
Hi, > On 21 Nov 2023, at 11:46, Poul-Henning Kamp wrote: > > I have played around with bl[ao]cklistd on 13.2 and I am not terribly > impressed: > [etc] We came up with a similar list of objections and built our own solution. -- Bob Bishop r...@gid.co.uk
bl[ao]cklistd, some first impressions...
I have played around with bl[ao]cklistd on 13.2 and I am not terribly impressed: A) It would be nice to be able to specify in bl[ao]cklistd.conf that violations of a particular rule should get the IP banned for any trafic, not just the one they happened to trigger first. This is particular necessary/useful for instance when you run a "HTTP-sandwich", and spot the problem in the inner layers, but want to block access to the exterior port 443 from a process which does not hold that socket. (ie: varnish behind hitch) B) The OaM commands for pf take obscurity to a new level: pfctl -a blacklistd/80 -sr -v pfctl -a blacklistd/80 -t port80 -T show and that is just for one specific port: repeat manually for all of 22, 25, 443 etc. Going to a default "totally block IP's" policy would simplify this. C) Anchor-wildcards do not work in pfctl and the diagnostics are criminal: root@test-net:~ # pfctl -a 'blacklistd/*' -t port80 -T show pfctl: Unknown error: -1. root@test-net:~ # pfctl -t port80 -T show pfctl: Unknown error: -1. D) It would be nice to be able to have bl[ao]cklistd cooperate across machines, so that for instance all VM's on the same hardware could benefit from each others detections. E) It should be possible to inject an entry with bl[ao]cklistctl, so that simple text-based processing of logfiles can contribute too. Other than that, once you get it set up right, it seems to get the job done... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
