When launching a daemon in the jail (as a specified user) /usr/sbin/daemon was exiting with return code 0 and not outputting anything in the syslogs. This happened on a jail I've erroneously upgraded from FreeBSD 13.2-RELEASE to FreeBSD 13.3-RELEASE on a system host with 13.2-RELEASE. I've seen other users mentioning similar issues on TrueNAS forums pinpointing to kqueuex() being the culprit for ABI incompatibility (https://www.truenas.com/community/threads/warning-dont-upgrade-your-truenas-core-jails-to-freebsd-13-3-just-yet.117018). Although my bug report is not about this, but more about the lack of information on the user that something wrong happened. I'd expect at minimum a different return code than 0 (and preferably an explicit error in the log too).
(In reply to skenizen from comment #0) > When launching a daemon in the jail (as a specified user) /usr/sbin/daemon was exiting with return code 0 and not outputting anything in the syslogs. > This happened on a jail I've erroneously upgraded from FreeBSD 13.2-RELEASE to FreeBSD 13.3-RELEASE on a system host with 13.2-RELEASE. For stable branches, the kernel ABI compatibility ensures that old binaries can still run on new kernels. i.e., 13.3 kernel with 13.2 userland. But not the opposite. > I've seen other users mentioning similar issues on TrueNAS forums pinpointing to kqueuex() being the culprit for ABI incompatibility (https://www.truenas.com/community/threads/warning-dont-upgrade-your-truenas-core-jails-to-freebsd-13-3-just-yet.117018). I think that is a good example to illuminate the ABI compatibility issue. > Although my bug report is not about this, but more about the lack of information on the user that something wrong happened. I'd expect at minimum a different return code than 0 (and preferably an explicit error in the log too). Run daemon(8) from FreeBSD 13.3 on 13.1: ``` root@:~ # /tmp/daemon -l daemon echo OK ld-elf.so.1: /tmp/daemon: Undefined symbol "kqueuex@FBSD_1.7" ``` The parent does return 0. The child will complain with "Undefined symbol".
> The parent does return 0. The child will complain with "Undefined symbol". truss(1) shows that clearly. ``` # truss -f /tmp/daemon -l daemon echo OK ... 1543: sigaction(SIGHUP,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0) 1544: <new process> 1543: fork() = 1544 (0x608) 1544: setsid() = 1544 (0x608) 1544: sigaction(SIGHUP,{ SIG_IGN SA_RESTART ss_t },0x0) = 0 (0x0) 1544: madvise(0x0,0,MADV_PROTECT) = 0 (0x0) 1544: pipe2(0x7fffffffe950,0) = 0 (0x0) ld-elf.so.1: 1544: write(2,"ld-elf.so.1: ",13) = 13 (0xd) /tmp/daemon: Undefined symbol "kqueuex@FBSD_1.7" 1544: write(2,"/tmp/daemon: Undefined symbol "k"...,48) = 48 (0x30) 1544: write(2,"\n",1) = 1 (0x1) 1544: exit(0x1) 1544: process exit, rval = 1 1543: exit(0x0) 1543: process exit, rval = 0 ```
Another truss(1) that show what happens when the `--close-fds` option is supplied. ``` # truss -f /tmp/daemon -fSl daemon echo OK ... 955: connect(3,{ AF_UNIX "/var/run/logpriv" },106) = 0 (0x0) 955: open("/dev/null",O_RDWR,00) = 4 (0x4) 955: sigaction(SIGHUP,{ SIG_IGN 0x0 ss_t },{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0) 956: <new process> 955: fork() = 956 (0x3bc) 956: setsid() = 956 (0x3bc) 956: sigaction(SIGHUP,{ SIG_IGN SA_RESTART ss_t },0x0) = 0 (0x0) 956: dup2(4,0) = 0 (0x0) 956: dup2(4,1) = 1 (0x1) 956: dup2(4,2) = 2 (0x2) 956: close(4) = 0 (0x0) 956: madvise(0x0,0,MADV_PROTECT) = 0 (0x0) 956: pipe2(0x7fffffffe950,0) = 0 (0x0) 956: write(2,"ld-elf.so.1: ",13) = 13 (0xd) 956: write(2,"/tmp/daemon: Undefined symbol "k"...,48) = 48 (0x30) 956: write(2,"\n",1) = 1 (0x1) 956: exit(0x1) 956: process exit, rval = 1 955: exit(0x0) 955: process exit, rval = 0 ``` So simply put, when `--close-fds` option is present, daemon(3) closes fd 0,1,2 and these fds are redirected to /dev/null but logfile or syslog is opened too late to catch error messages.