xfs -port -1 produces _FontTransSocketINETCreateListener: Unable to get service for -1 _FontTransMakeAllCOTSServerListeners: failed to create listener for tcp On the other hand, xfs -port 7100 works fine, and I can then do xset +fp tcp/localhost:7100 as usual. I reported this on redhat-devel and someone responded that they had had exactly the same problem with no resolution.
The options -droppriv -daemon used in the init.d/xfs script seem to have some effect on this: xfs -droppriv -daemon -port -1 doesn't work, but xfs -daemon -port -1 *does*. Are these options documented anywhere?
these will be documented in XFree86-3.3.6-12 and later.
So how does telling us about vapourware documentation "resolve" the problem? I don't know how to start xfs safely. Either I use a tcp port, opening a security hole, or I seem to have to not drop root privileges. The xfs script in init.d doesn't work on my system.
I run RH 6.1. After updating several new packages from the Errata page xfs stopped working (it wouldn't startup) for me too except if I remove -droppriv option from xfs startup script (that is now: daemon xfs -daemon -port -1, instead of daemon xfs -droppriv -daemon -port -1). However in that case xfs starts and stays as root which is a security hole, and should not be like this. I updated only these packages to the latest versions available from the Errata: lpr-0.48-1.i386.rpm pam-0.68-10.i386.rpm usermode-1.18-1.i386.rpm sharutils-4.2.1-1.6.1.i386.rpm groff-1.15-1.i386.rpm groff-gxditview-1.15-1.i386.rpm libtiff-3.5.4-1.i386.rpm libtiff-devel-3.5.4-1.i386.rpm Now, I am not sure how these packages may affect xfs, but the fact is that before the update everything worked fine. So, since now there is a security hole, I would ask you please to fix this as soon as possible. Thanks.
I have the same problem. The only difference is that it happened after I rebuilt the kernel to increase IPC resources. Now, xfs fails with both kernels unless I delete the droppriv option from xfs invocation. xfs and its configuration file have not been changed due to kernel rebuild. Why does kernel build affect xfs functionality? Also, the same problem reported back in 6.0 with bug 4540.
what error does xfs report when started with -droppriv? It should be reporting some sort of error if there is a problem. We can't duplicate this here. If someone can provide an strace of the situation or some error output, it would help a lot.
The problem was caused on my box by a fonts.dir file that wasn't world readable. Thanks to Preston Brown, who figured it out from an strace -f.