[Bug 278342] daemon(8): -R doesn't restart supervised process
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278342
Bug ID: 278342
Summary: daemon(8): -R doesn't restart supervised process
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: sig...@gmail.com
When certain other options are also specified it might work correctly, but with
-R alone, "supervise mode" doesn't kick in. Using -R alone used to work on
previous versions.
diff --git i/usr.sbin/daemon/daemon.c w/usr.sbin/daemon/daemon.c
index da8e4895e19b..52fbfca1dcd2 100644
--- i/usr.sbin/daemon/daemon.c
+++ w/usr.sbin/daemon/daemon.c
@@ -240,12 +240,13 @@ main(int argc, char *argv[])
case 'R':
state.restart_enabled = true;
state.restart_delay = strtol(optarg, , 0);
if (p == optarg || state.restart_delay < 1) {
errx(6, "invalid restart delay");
}
+ state.mode = MODE_SUPERVISE;
break;
case 's':
state.syslog_priority = get_log_mapping(optarg,
prioritynames);
if (state.syslog_priority == -1) {
errx(4, "unrecognized syslog priority");
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 271651] MINIMAL-based NOINET kernel build fails after base 98d06eea14a5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271651 (intentionally left blank) changed: What|Removed |Added Status|Open|Closed Resolution|--- |FIXED --- Comment #2 from (intentionally left blank) --- Should be fixed after base 042fb58d009e -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278340] unix(4): regressed after base aba79b0f4a3f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278340
Bug ID: 278340
Summary: unix(4): regressed after base aba79b0f4a3f
Product: Base System
Version: 15.0-CURRENT
Hardware: Any
OS: Any
Status: New
Keywords: regression
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: throwaway_vthg...@protonmail.com
CC: gleb...@freebsd.org
$ truss swaymsg -t get_outputs
[...]
socket(PF_LOCAL,SOCK_STREAM,0) = 3 (0x3)
connect(3,{ AF_UNIX "/var/run/xdg/foo/sway-ipc.1001.27613.sock" },106) = 0
(0x0)
setsockopt(3,SOL_SOCKET,SO_RCVTIMEO,0x820bb96a8,16) = 0 (0x0)
write(3,"i3-ipc\0\0\0\0\^C\0\0\0",14) = 14 (0xe)
write(3,0x825f64008,0) ERR#14 'Bad address'
00:00:00.000 write(2,"00:00:00.000 ",13)= 13 (0xd)
ioctl(2,TIOCGETA,0x820bb9504) = 0 (0x0)
write(2,"\^[[1;31m",7) = 7 (0x7)
[common/ipc-client.c:140] Unable to send IPC payload
write(2,"[common/ipc-client.c:140] Unable"...,52) = 52 (0x34)
ioctl(2,TIOCGETA,0x820bb9504) = 0 (0x0)
write(2,"\^[[0m",4) = 4 (0x4)
write(2,"\n",1) = 1 (0x1)
exit(0x1)
process exit, rval = 1
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277717] kernel using 100% CPU in arc_prune in 13.3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277717 Vladimir Druzenko changed: What|Removed |Added CC||v...@freebsd.org --- Comment #9 from Vladimir Druzenko --- (In reply to Trev from comment #8) Look like fix was committed to stable/13 several hours ago only: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275594#c115 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278311] amdtemp: Does not recognize AMD Threadripper 7960X
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311 --- Comment #13 from Joel Bodenmann --- Thank you for the explanation. That is pretty much what I expected/understood but I wasn't sure whether you're hinting at something I'm unaware of. dmesg (attached) hedt1% sysctl dev.amdtemp dev.amdtemp.0.core0.sensor0: -0.0C dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.%parent: hostb24 dev.amdtemp.0.%pnpinfo: dev.amdtemp.0.%location: dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.%parent: -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278311] amdtemp: Does not recognize AMD Threadripper 7960X
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311 Joel Bodenmann changed: What|Removed |Added Attachment #249916|0 |1 is obsolete|| --- Comment #12 from Joel Bodenmann --- Created attachment 249938 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249938=edit dmesg -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278311] amdtemp: Does not recognize AMD Threadripper 7960X
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311 --- Comment #11 from Xin LI --- (In reply to Joel Bodenmann from comment #10) > could you elaborate what kind of information would show up in dmesg that > would be considered sensitive? Well, I'm just trying to remind you that you should filter out what _you_ would consider sensitive, as the kernel message buffer (`dmseg`) could contain a lot of things, because bugzilla data is generally accessible by anyone. Example of "sensitive data" can include e.g. build host name, ethernet address, hard drive serial number, file system mounted, etc. Some people feel uncomfortable to share some of these information with the Internet, which is totally understandable and should always be respected, and usually these PIIs are not useful for debugging anyways (but information like the which other drivers were loaded, or e.g. what drivers said without indicating them in the same line, especially in verbose boot, are very important for debugging, so I generally attach a full dmesg output when reporting driver issues with only minimal redaction). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 235136] cron email header has bogus date value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235136 --- Comment #2 from Mike Lempriere --- I barely even remember this one... I worked around my issue by lowering spamassassin scores, so haven't paid it further attention. However, looking closely now at email source headers, I am still seeing DATE_IN_FUTURE_03_06 in my built-in "daily run" cron emails. The Received headers and Date all agree on the time of 03:02:03. This job (I believe) is started by /etc/crontab which shows: 1 3 * * * rootperiodic daily meaning it starts at 03:01. Just trying 'periodic daily' on the command line it's about a min to run, and that's what we're seeing in the email header. Here's the sample I'm looking at: Date: Sat, 6 Apr 2024 03:02:03 -0700 (PDT) Looking at RFC 2822, I'm not sure that the closing "(PDT)" is compliant, so perhaps the fault could be considered to be cron. However, if this is compliant, and this is my incomplete understanding of the RFC, that would mean that cron is fine, and spamassassin is misunderstanding the headers. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278311] amdtemp: Does not recognize AMD Threadripper 7960X
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311 --- Comment #10 from Joel Bodenmann --- You have me slightly concerned now... could you elaborate what kind of information would show up in dmesg that would be considered sensitive? I guess one could argue about MAC addresses if being extra paranoid - is there anything else I'm unaware of? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278311] amdtemp: Does not recognize AMD Threadripper 7960X
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311 --- Comment #9 from Xin LI --- (In reply to Joel Bodenmann from comment #8) can you share the dmesg output (ideally with only sensitive information redacted) and `sysctl dev.amdtemp` output? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278311] amdtemp: Does not recognize AMD Threadripper 7960X
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278311 --- Comment #8 from Joel Bodenmann --- After applying your latest patch I am getting corresponding entries as dev.cpu.*.temperature. However, all of them report -0.0 Nothing shows up in dmesg.boot that would indicate anything helpful. hedt1% sysctl -a | grep amdtemp kern.version: FreeBSD 14.0-STABLE #2 feature/amdtemp-n267180-b556c37f83b0-dirty: Fri Apr 12 17:28:54 UTC 2024 FreeBSD 14.0-STABLE #2 feature/amdtemp-n267180-b556c37f83b0-dirty: Fri Apr 12 17:28:54 UTC 2024 amdtemp0: on hostb24 dev.amdtemp.0.core0.sensor0: -0.0C dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.%parent: hostb24 dev.amdtemp.0.%pnpinfo: dev.amdtemp.0.%location: dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.%parent: -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263234] Add support for OpenZFS encryption to adduser
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263234 --- Comment #5 from John Grafton --- Merged: https://github.com/freebsd/freebsd-src/commit/215c0a5158f17f515f365fc28a9ff0b367be8fc9 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278333] clang-18 crashes on the port audio/noise-suppression-for-voice-lv2: Assertion failed: (result && "no existing substitution for template name"), function mangleExistingSubstitution, file [
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278333 Yuri Victorovich changed: What|Removed |Added Assignee|b...@freebsd.org|toolch...@freebsd.org Hardware|Any |amd64 URL||https://pkg-status.freebsd. ||org/beefy18/data/main-amd64 ||-default/pb7573d3199cc_sfb8 ||a8333b48/logs/noise-suppres ||sion-for-voice-lv2-1.03_1.l ||og CC||d...@freebsd.org Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278333] clang-18 crashes on the port audio/noise-suppression-for-voice-lv2: Assertion failed: (result && "no existing substitution for template name"), function mangleExistingSubstitution, file [
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278333 Bug ID: 278333 Summary: clang-18 crashes on the port audio/noise-suppression-for-voice-lv2: Assertion failed: (result && "no existing substitution for template name"), function mangleExistingSubstitution, file [...]/AST/ItaniumMangle.cpp Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: y...@freebsd.org This port wasn't changed recently, but clang-18 now crashes. See the URL for the log. -- You are receiving this mail because: You are the assignee for the bug.
