Hide Forgot
Description of problem: openstack-swift-object-server will fail to start because it can't bind to 0.0.0.0:6000 if gdm/X is started before Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. enable gdb and reboot 2. 3. Actual results: When heat will try uploading/deleting files openstack-swift-object-server will die Expected results: Not die Additional info:
It appears that port tcp/6000 is reserved for X11: [root@knox ~]# cat /etc/services |grep 6000\/tcp |head -1 x11 6000/tcp X # the X Window System
One quick thing we can do here is to change port 6000 to something else OR make sure gdm/x11 are using other ports OR disable gdm/X11 when running "openstack undercloud install" ...
Hi David, yeah the 6000 range is an older range once used. openstack.org docs for swift now introduce 6200, 6201, 6202. if you could change to those you wouldn't clash with the x server and you'd also be inline with the current recommended settings. should just need to change the settings and restart your account/container/object servers. let me know if there is anything else or if we can close this. thanks a lot, Mike Abrams
Well the problem is instack-undercloud that uses port 6000 for that while gdm/X are also using port 6000 . This is in OSP13 .
So in your /home/stack/undercloud.conf you want to have something like: hieradata_override = /home/stack/hiera_override.yaml And then in /home/stack/hiera_override.yaml you can add: swift::storage::all::object_port: "6200" (I tested this on OSP10 and it works okay)
(In reply to Mike Abrams from comment #3) > yeah the 6000 range is an older range once used. > > openstack.org docs for swift now introduce 6200, 6201, 6202. if you could > change to those you wouldn't clash with the x server and you'd also be > inline with the current recommended settings. > > should just need to change the settings and restart your > account/container/object servers. Please don't change the ports lightly, this will break existing deployments and might even result in a data loss. The ports are also in the rings, and depending on the deployment this will not be changed automatically. Related upstream discussion: https://bugs.launchpad.net/swift/+bug/1341952/comments/1 Personally I think X should not run on any undercloud node at all, and I currently don't see benefits in doing so. It's usually accessed remotely by SSH and the webinterface AFAIK, and being a server node it might make more sense to restrict the number of running services with ports exposed to the world to limit security issues. All that said, we can't fix this easily on the TripleO side, thus the right way for now is to either disable X or run it on a different port.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1579105