Apache2 could not bind to address after vSphere upgrade | SUSE Communities

Apache2 could not bind to address after vSphere upgrade


After the upgrade from vSphere 4.0x to vSphere 4.1 or ESXi 4 to ESXi4.1 apache on a OES 2 server wouldn’t start with the error:

apache2 could not bind to address after vSphere upgrade

As you all probably know TCP port 631 is for IPP print, or for us Novell guy’s iPrint. iPrint is started with apache (the website that is). But if iPrint cannot start, apache wouldn’t start also. So what’s blocking TCP port 631? The must be another service that’s using TCP port 631 for ipp printing. After some investigation I discovered that CUPS was started on the OES 2 server. And CUPS also uses ipp and so TCP port 631. So shutting down CUPS enabled me to start apache (rcapache start). Of course you have to make sure that CUPS isn’t started by default anymore on boot time (insserv -r /etc/init.d/cups).

But what started CUPS because it wasn’t started at boot time before. The only change that was made on the OES 2 was the upgrade of the VMware tools. So that was it.

I must say, not really nice of VMware to enable the start of daemons that weren’t started by default before? I don’t know what the reason is why they want to start CUPS for the VMware tools? So if you know the reason, let me know!

More blog post on Open Enterprise Server on VMware? Blog WilmsenIT

(Visited 1 times, 1 visits today)


  • smflood says:

    Later versions of VMware Tools now install something called ThinPrint that gives you virtual printing from within your virtual machine.

    The problem, at least as far as OES Linux VMs are concerned, is that it installs CUPS to provide this functionality which as your article states causes trouble for iPrint.

    So the solution is to stop CUPS running as part of the VMware Tools (or don’t use them in the first place).

    Fortunately Novell have just published TID #7007214.

    Note that this is an issue with VMware Tools (ThinPrint is installed on Windows VMs too but obviously doesn’t affect OES Linux installs!) rather than VMware ESX[i] so you will see this if using VMware Workstation, for example.

  • buddhagw says:

    Feel free to open an SR with VMware about this. It’s not a behavior I’d like to see continue in VMware tools. If you’d like a reference, my VMware SR about this is #1594614331. There is a Feature Request form here (http://www.vmware.com/support/policies/feature.html) as another means of expressing any concerns.

  • Leave a Reply

    Your email address will not be published.