fcgiwrap won't start

Hi,

I'm using 13.4-RELEASE-p2 in a TrueNAS jail. It has worked for months without issues. But now I run into the problem that fcgiwrap won't start and I don't know why.

rc.conf:

Code:
fcgiwrap_enable="YES"
fcgiwrap_user="www"
fcgiwrap_group="www"
fcgiwrap_socket_owner="www"
fcgiwrap_socket_group="www"
fcgiwrap_socket_mode="0660"

Code:
root@www:~ # service fcgiwrap status
fcgiwrap is not running.
root@www:~ # service fcgiwrap start
Starting fcgiwrap. <5s pause>
chmod: /var/run/fcgiwrap/fcgiwrap.sock: No such file or directory
root@www:~ # service fcgiwrap status
fcgiwrap is not running.

The socket /var/run/fcgiwrap/fcgiwrap.sock is not created, but an empty /var/run/fcgiwrap/fcgiwrap.pid is present. I've created a vanilla 13.4 VM and it works without issues there. But in my jail it fails and I don't know why. Starting fcgiwrap manually works as well:

Code:
root@www:~ # fcgiwrap -s unix:/var/run/fcgiwrap/fcgiwrap.sock
→ runs and socket is created

So it appears there's an issue with how fcgiwrap is launched by “service fcgiwrap start”. How to find out what's wrong?

version: fcgiwrap-1.1.0_12
 
My additional settings
Bash:
fcgiwrap_profiles="gitweb"
fcgiwrap_gitweb_socket="unix:/var/run/fcgiwrap/gitweb.socket"
Owner folder /var/run/fcgiwrap is www user.
 
I don't use profiles and changed rc.conf to
Code:
fcgiwrap_enable="YES"
fcgiwrap_user="www"
fcgiwrap_group="www"
fcgiwrap_socket_owner="www"
fcgiwrap_socket_group="www"
fcgiwrap_socket_mode="0660"
fcgiwrap_socket="unix:/var/run/fcgiwrap/fcgiwrap.sock"
Same problem. Permissions /var/run/fcgiwrap:
Code:
drwxrwxrwt  2 root  wheel      2 Dec 19 16:50 fcgiwrap
 
Ownership of the /var/run/fcgiwrap is now wrong, probably should be www:www, not root:wheel. But given that it is world-writable, that should be OK. I'm a little surprised that the directory is sticky; if there is already a fcgiwrap.sock file in there, it might cause trouble if the file is owned by root.

And: when the fcgiwrap executable actually starts, can you see whether it is running as www:www, and what its effective UID and GID is? All those are visible with ps. But it might stop so fast that you can't even find it with ps.

And then check the file /usr/local/etc/rc.d/fcgiwrap, whether it does setting of UID and GID correctly.
 
There is no fcgiwrap.sock file. I think that's the whole issue here. If the file would exist, it'd mean that fcgiwrap would run, which it doesn't. And no, I can't observe fcgiwrap starting. I've tried, but it either never starts or is exists immediately. As I mentioned before, an fcgiwrap.pid file is created. But it's empty. Does that mean that fcgiwrap never started?

I'm not sure if /usr/local/etc/rc.d/fcgiwrap sets the UID and GID correctly. I assume it does:
Code:
…
        install -d -o root -g wheel -m 1777 /var/run/fcgiwrap
…
        if [ "${fcgiwrap_socket_owner}" != "${fcgiwrap_user}" ]; then
                chown ${fcgiwrap_socket_owner} ${fcgiwrap_socket#unix:}
        fi
        if [ "${fcgiwrap_socket_group}" != "${fcgiwrap_group}" ]; then
                chgrp ${fcgiwrap_socket_group} ${fcgiwrap_socket#unix:}
        fi
…
I believe that's the call that generates the error
Code:
chmod: /var/run/fcgiwrap/fcgiwrap.sock: No such file or directory
fcgiwrap doesn't start, the socket is not created and chmod fails. The permissions on the directory should be fine if I interpret that correctly.
 
I experienced the same thing and figured it out using truss. My TrueNAS is running 13.0-RELEASE but the jail I made (and the only option for new jails) uses 13.5-RELEASE; apparently between those versions FreeBSD got a new kqueuex system call, which the host kernel does not support (error is "function not implemented"), so some daemons (including fcgiwrap) will silently fail to start.

As described in https://www.truenas.com/community/t...s-core-jails-to-freebsd-13-3-just-yet.117018/ the fix is to replace the /usr/sbin/daemon in the affected jail(s) with the older version from the host system. The instructions given there didn't work for me exactly because the filesystems comprising the 13.5-RELEASE are read-only:

/mnt/z/iocage/releases/13.5-RELEASE/root/usr/sbin on /mnt/z/iocage/jails/zoneminder/root/usr/sbin (nullfs, local, read-only, nfsv4acls)

But what did end up working was to do (outside the jail):

sh:
zfs set readonly=off z/iocage/releases/13.5-RELEASE/root
cp -p /usr/sbin/daemon /mnt/z/iocage/releases/13.5-RELEASE/root/usr/sbin
zfs set readonly=on z/iocage/releases/13.5-RELEASE/root
 
My TrueNAS is running 13.0-RELEASE but the jail I made (and the only option for new jails) uses 13.5-RELEASE
You cannot run a newer version userland (jailed or otherwise) on an older kernel. Not supported, never was, never will be. There's backwards compatibility in the kernel, not forward compatibility.

That is besides the fact that TrueNAS is not supported here. And 13.0-RELEASE has been EoL since August 2022.
 
Back
Top