cPanel 11.28.45 - upcp and ipaliases (not restarting)

We had a server that had a reported outage tonight, we nailed it down to happening during the /scripts/upcp that runs nightly and it looks as though cPanel restarted networking without restarting ipaliases causing any secondary routed IP addresses to fail.

Has anybody else experienced this issue? In talking with a couple of other providers - they've seen it a couple of times but it appears to be rare but with the type of outage this can cause even once is too often in my opinion.

 

http://www.screen-shot.net/2010-11-25_0305.png
http://www.screen-shot.net/2010-11-25_0305_001.png

Ultimately I think that the ipaliases start/restart/whatever should be removed from the update script.

 

Netmasks are 255.255.255.0. Ticket ID is 1047278 if you want to take a look - in speaking with about a dozen providers ... I'm not the only one to see this as of 11.28.

This was a fresh CentOS5 install with a fresh cPanel 11.28 installation - all IP addresses besides the primary on eth0 were added via WHM.

At this point it looks like we're going to have to remove the cron for /scripts/upcp until this is resolved. I still see no reason why upcp runs anything having to do with ip aliasing...

 

Honestly I feel like this is being blown off... I guess the only option at this point until somebody at cPanel decides that running ipaliases on every /scripts/upcp isn't a good idea is to disable the cron job and run it manually and then check to make sure the IPs bound the way they were supposed to.

I really shouldn't have to actively disable features of cPanel so that our servers don't experience issues.

 

Not sure what is going on with cPanel's MySQL but my last post disappeared so I'm going to re-post it (I happened to save a copy of the thread just before this happened).

Edit: Looks like the MySQL servers re-converged.

 

The code from 11.25 /scripts/upcp:

Code:

if ( -x '/sbin/chkconfig' ) {
        $output .= cPScript::WHMAPI::setstatus('Setting up ip startup');
        cPScript::SafeRun::Errors::saferunnoerror( '/sbin/chkconfig', '--add',     'ipaliases' );
        cPScript::SafeRun::Errors::saferunnoerror( '/sbin/chkconfig', '--level',   '35', 'ipaliases', 'on' );
        cPScript::SafeRun::Errors::saferunnoerror( '/sbin/chkconfig', 'ipaliases', '35' );
        $output .= cPScript::WHMAPI::setstatusdone();
    }

The code from 11.28 /scripts/upcp:

Code:

    $output .= Cpanel::WHMAPI::setstatus('Setting up ip startup');

    if ( -x '/scripts/cpservice' ) {
        $output .= Cpanel::WHMAPI::status_cmd( '/scripts/cpservice', 'ipaliases', 'enable', '35' );
        my $ipaliases_start = Cpanel::SafeRun::Errors::saferunallerrors('/scripts/cpservice', 'ipaliases', 'start' );
        $ipaliases_start =~ s/S[^\:]+:\s*File\s*exists\s*\[\s*FAILED\s*\]/\[ UP \]/g; # if it is already in the routing table we do not need to throw an err$
        print $ipaliases_start;
        $output .= $ipaliases_start;
    }
    else {
        $output .= Cpanel::WHMAPI::setstatus('/scripts/cpservice is missing or not executable.');
    }

    $output .= Cpanel::WHMAPI::setstatusdone();

Uggghhh.... Why change this? In 11.25 it made sure that the service was set to start on boot - in 11.28 for some reason it physically tries starting it every time the update runs... This makes no sense.

What this function did in 11.25 and earlier was make sure that the service ipaliases was set to start on boot (which makes sense)... 11.28 for whatever reason "Setting up ip startup" (i.e. setting it to start on boot) isn't really that at all.

 

I was referring to the feeling I got from that one specific response. It was escalated because I asked for it and I appreciate it.

Thank you.

 

We've done the same.

 

I've not yet been notified that it's been fixed - I do believe that they reverted the way /scripts/upcp works with IPs until an official fix is in place.

 

Yes, it was fixed in newer revisions of cPanel.