On Jan 31, 2026, at 14:30, Doug Hardie <bc979@lafn.org> wrote:
AMD machine. Just upgraded to 15.0. Everything works except for syslogd which crashes on startup. Debug output:
sermons# /usr/sbin/syslogd -sd
new socket fd is 6
shutdown
sending on socket
new socket fd is 7
shutdown
sending on socket
Trying peer: /var/run/log
new socket fd is 8
listening on socket
sending on socket
Trying peer: /var/run/logpriv
new socket fd is 10
listening on socket
sending on socket
off & running....
init
cfline("*.err;kern.warning;auth.notice;mail.crit /dev/console", f, "-wn,wnssl,wncert", "*", "*")
cfline("*.notice;authpriv.none;kern.debug;mail.crit;wn.crit;wnssl.crit;wncert.crit /var/log/messages", f, "-wn,wnssl,wncert", "*", "*")
Failed to xfer configuration nvlist: Socket is not connected
logmsg: pri 53, flags 0, from sermons, msg Failed to xfer configuration nvlist: Socket is not connected
Logging to CONSOLE /dev/console
bt from core dump:I found a resolution for this. Something in the syslogd.conf that worked before is no longer working. I think it has something to do with the extract of that file listed in the error messages. I copied the file from a working system to this system and now syslogd starts properly. I didn't find anything significantly different between the two files, but it must be there somewhere. Anyway, syslog is once again working properly.
lldb -c /crash/syslogd.core /usr/sbin/syslogd
(lldb) target create "/usr/sbin/syslogd" --core "/crash/syslogd.core"
Core file '/crash/syslogd.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'syslogd', stop reason = signal SIGSEGV
* frame #0: 0x000003cb288c68b3 syslogd`___lldb_unnamed_symbol345 + 339
frame #1: 0x000003cb288c6477 syslogd`___lldb_unnamed_symbol344 + 1271
frame #2: 0x000003cb288c5f0e syslogd`___lldb_unnamed_symbol343 + 62
frame #3: 0x000003cb288cbccd syslogd`___lldb_unnamed_symbol368 + 125
frame #4: 0x000003d34c648ffb libcasper.so.1`service_message + 187
frame #5: 0x000003d34c6495e5 libcasper.so.1`service_start + 1029
frame #6: 0x000003d34c6484d7 libcasper.so.1`service_execute + 167
frame #7: 0x000003d34c649a68 libcasper.so.1`___lldb_unnamed_symbol156 + 424
frame #8: 0x000003d34c6498b9 libcasper.so.1`zygote_init + 169
frame #9: 0x000003d34c64850b libcasper.so.1`casper_main_loop + 27
frame #10: 0x000003d34c6479ad libcasper.so.1`cap_init + 173
frame #11: 0x000003cb288c47ef syslogd`___lldb_unnamed_symbol337 + 191
frame #12: 0x000003cb288c3adf syslogd`___lldb_unnamed_symbol334 + 3455
frame #13: 0x000003d34d8cf37f libc.so.7`__libc_start1 + 303
frame #14: 0x000003cb288c2ce1 syslogd`___lldb_unnamed_symbol332 + 33
This works fine on a Raspberry PI 5. I can't find any differences between them other than I had to add
syslogd_oomprotect="NO"
to /etc/rc.conf. Otherwise protect complained about a bad or missing argument
How can I get syslogd working again?
AMD machine. Just upgraded to 15.0. Everything works except for syslogd which crashes on startup. Debug output:
sermons# /usr/sbin/syslogd -sd
new socket fd is 6
shutdown
sending on socket
new socket fd is 7
shutdown
sending on socket
Trying peer: /var/run/log
new socket fd is 8
listening on socket
sending on socket
Trying peer: /var/run/logpriv
new socket fd is 10
listening on socket
sending on socket
off & running....
init
cfline("*.err;kern.warning;auth.notice;mail.crit /dev/console", f, "-wn,wnssl,wncert", "*", "*")
cfline("*.notice;authpriv.none;kern.debug;mail.crit;wn.crit;wnssl.crit;wncert.crit /var/log/messages", f, "-wn,wnssl,wncert", "*", "*")
Failed to xfer configuration nvlist: Socket is not connected
logmsg: pri 53, flags 0, from sermons, msg Failed to xfer configuration nvlist: Socket is not connected
Logging to CONSOLE /dev/console
On Feb 1, 2026, at 07:14, Mark Johnston <markj@FreeBSD.org> wrote:
On Sat, Jan 31, 2026 at 02:30:35PM -0800, Doug Hardie wrote:
AMD machine. Just upgraded to 15.0. Everything works except for syslogd which crashes on startup. Debug output:
sermons# /usr/sbin/syslogd -sd
new socket fd is 6
shutdown
sending on socket
new socket fd is 7
shutdown
sending on socket
Trying peer: /var/run/log
new socket fd is 8
listening on socket
sending on socket
Trying peer: /var/run/logpriv
new socket fd is 10
listening on socket
sending on socket
off & running....
init
cfline("*.err;kern.warning;auth.notice;mail.crit /dev/console", f, "-wn,wnssl,wncert", "*", "*")
cfline("*.notice;authpriv.none;kern.debug;mail.crit;wn.crit;wnssl.crit;wncert.crit /var/log/messages", f, "-wn,wnssl,wncert", "*", "*")
Failed to xfer configuration nvlist: Socket is not connected
logmsg: pri 53, flags 0, from sermons, msg Failed to xfer configuration nvlist: Socket is not connected
Logging to CONSOLE /dev/console
The underlying problem is that "wn", "wnssl", "wncert" are not valid
syslog facilities, so the configuration parser fails. Due to a bug, it doesn't give you a useful message in this case. Before, the parser was
less strict; we perhaps should restore the old behaviour.
Here is a patch that partly addresses the proble: https://reviews.freebsd.org/D55033
On Feb 1, 2026, at 07:14, Mark Johnston <markj@FreeBSD.org> wrote:
On Sat, Jan 31, 2026 at 02:30:35PM -0800, Doug Hardie wrote:
AMD machine. Just upgraded to 15.0. Everything works except for syslogd which crashes on startup. Debug output:
sermons# /usr/sbin/syslogd -sd
new socket fd is 6
shutdown
sending on socket
new socket fd is 7
shutdown
sending on socket
Trying peer: /var/run/log
new socket fd is 8
listening on socket
sending on socket
Trying peer: /var/run/logpriv
new socket fd is 10
listening on socket
sending on socket
off & running....
init
cfline("*.err;kern.warning;auth.notice;mail.crit /dev/console", f, "-wn,wnssl,wncert", "*", "*")
cfline("*.notice;authpriv.none;kern.debug;mail.crit;wn.crit;wnssl.crit;wncert.crit /var/log/messages", f, "-wn,wnssl,wncert", "*", "*")
Failed to xfer configuration nvlist: Socket is not connected
logmsg: pri 53, flags 0, from sermons, msg Failed to xfer configuration nvlist: Socket is not connected
Logging to CONSOLE /dev/console
The underlying problem is that "wn", "wnssl", "wncert" are not valid
syslog facilities, so the configuration parser fails. Due to a bug, it doesn't give you a useful message in this case. Before, the parser was less strict; we perhaps should restore the old behaviour.
Here is a patch that partly addresses the proble: https://reviews.freebsd.org/D55033
I am not convinced that passing errors like that is appropriate. Yes it used to work, but I think that was a mistake now. Syslogd should generate an error message in this situation and then possibly ignore the incorrect entries as if they were not there.
The underlying problem is that "wn", "wnssl", "wncert"
are not valid syslog facilities, so the configuration
parser fails. Due to a bug, it doesn't give you a
useful message in this case. Before, the parser was
less strict; we perhaps should restore the old
behaviour.
On Feb 3, 2026, at 06:08, Mark Johnston <markj@FreeBSD.org> wrote:Excellent
On Mon, Feb 02, 2026 at 03:45:06PM -0800, Doug Hardie wrote:
On Feb 1, 2026, at 07:14, Mark Johnston <markj@FreeBSD.org> wrote:
On Sat, Jan 31, 2026 at 02:30:35PM -0800, Doug Hardie wrote:
AMD machine. Just upgraded to 15.0. Everything works except for syslogd which crashes on startup. Debug output:
sermons# /usr/sbin/syslogd -sd
new socket fd is 6
shutdown
sending on socket
new socket fd is 7
shutdown
sending on socket
Trying peer: /var/run/log
new socket fd is 8
listening on socket
sending on socket
Trying peer: /var/run/logpriv
new socket fd is 10
listening on socket
sending on socket
off & running....
init
cfline("*.err;kern.warning;auth.notice;mail.crit /dev/console", f, "-wn,wnssl,wncert", "*", "*")
cfline("*.notice;authpriv.none;kern.debug;mail.crit;wn.crit;wnssl.crit;wncert.crit /var/log/messages", f, "-wn,wnssl,wncert", "*", "*")
Failed to xfer configuration nvlist: Socket is not connected
logmsg: pri 53, flags 0, from sermons, msg Failed to xfer configuration nvlist: Socket is not connected
Logging to CONSOLE /dev/console
The underlying problem is that "wn", "wnssl", "wncert" are not valid
syslog facilities, so the configuration parser fails. Due to a bug, it
doesn't give you a useful message in this case. Before, the parser was
less strict; we perhaps should restore the old behaviour.
Here is a patch that partly addresses the proble:
https://reviews.freebsd.org/D55033
I am not convinced that passing errors like that is appropriate. Yes it used to work, but I think that was a mistake now. Syslogd should generate an error message in this situation and then possibly ignore the incorrect entries as if they were not there.
That's what the change is doing, after I updated the patch.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 00:54:04 |
| Calls: | 810 |
| Files: | 1,287 |
| Messages: | 198,761 |