SUSE Conversations


Apache2 could not bind to address 0.0.0.0:631 after vSphere upgrade



By: mwilmsen

November 17, 2010 5:07 pm

Reads:358

Comments:2

Rating:0

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 0.0.0.0:631 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

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Tags: , ,
Categories: Open Enterprise Server on SLES, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

2 Comments

  1. By:smflood

    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.

  2. By:buddhagw

    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.

Comment

RSS