Bug 9234 - xfs -port -1 failure
xfs -port -1 failure
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Preston Brown
Depends On:
  Show dependency treegraph
Reported: 2000-02-08 13:18 EST by rdt
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-30 14:46:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description rdt 2000-02-08 13:18:26 EST
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.
Comment 1 rdt 2000-02-09 07:04:59 EST
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?
Comment 2 Preston Brown 2000-02-10 15:11:59 EST
these will be documented in XFree86-3.3.6-12 and later.
Comment 3 rdt 2000-02-10 15:32:59 EST
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.
Comment 4 snikhi1 2000-03-10 08:44:59 EST
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.
Comment 5 Anonymous 2000-04-25 09:35:59 EDT
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.
Comment 6 Preston Brown 2000-05-30 14:46:59 EDT
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.
Comment 7 rdt 2000-05-31 08:44:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.