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:
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.
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
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.