# PHP issue after power failure on Apache/Mysql/Php box

## mlnzigzag

Hi, i've had a power failure to a customer's server. The unclean shutdown made some mysql tables unreadable, and i repaired it trough mysqlcheck. After that, i found some errors in almost any php pages.

Errors are as follows:

```
Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() error -3 in /var/www/localhost/htdocs/medicomd/mainfile.php on line 39

Warning: Cannot modify header information - headers already sent by (output started at /var/www/localhost/htdocs/medicomd/mainfile.php:39) in /var/www/localhost/htdocs/medicomd/mainfile.php on line 178

not connected
```

here you can see lines 39 and 178 of mainfile.php if it can help; i didn't put all the file, as it is more than 1K lines

```
  39   if (preg_match("/([OdWo5NIbpuU4V2iJT0n]{5}) /", rawurldecode($loc=$_SERVER["QUERY_STRING"]), $matches)) {

   178      setcookie("lang",$language,time()+31536000);

```

Thanks a lot in advance for your help. It would be highly appreciated!

If needed, it's easy for me to provide more useful informations. Please feel free to ask!

Marco

----------

## pappy_mcfae

I would advise to reinstall all the affected packages. Also, if you have a backup, now would be the time to deploy it. If you don't, start from scratch (remove and reinstall packages).

Blessed be!

Pappy

----------

## mlnzigzag

Unfortuantely i already did that. Exactly, i did as follows:

restarted the server with a knoppix cd and run e2fsck: it found and corrected many errors.

Reinstalled the compiled backed up packages mysql, apache, php. Same versions that was installed at the time of the power failure.

Then, i've restored the backup of the htdocs folder of apache.

I did not restored the backup of the mysql database, as it was too old and not useful. I've fixed the tables with errors by mysqlcheck --auto-repair.

All the tables were succesfully repaired.

I still receive this error in every mysql/php page i view on this apache server.

Any further help will be highly appreciated.

Thanks a lot pappy for your help

Marco

----------

## Mad Merlin

You could try emerging libpcre again. Also, did your php.ini get corrupted?

----------

## mlnzigzag

 *Mad Merlin wrote:*   

> You could try emerging libpcre again. Also, did your php.ini get corrupted?

 

i'm trying to re-emerge libpcre; i forgot to say that i already did a diff of the config files of the packages with the ones backed up and found no differences at all

i'll let you know how about libpcre

thanks a lot for your help

Marco

----------

## mlnzigzag

no differences between config files in the backup (pre power failure)

nothing changed recompiling libpcre

any further tries?

----------

## pappy_mcfae

As a matter of fact, I had one of my machines get messed up by a lightning-strike induced power failure. Here is what I did to get things back in order:

1) recompile gcc to make sure it didn't get hurt.

2) recompile the kernel, as it most likely did take a hit. 

3) emerge -aev system world

4) if the issue remains after, remove and reemerge apache, php, and any other associated packages.

5) if issue remains after that, reinstall all

Fortunately for me, after I finished step 3, all was well again. Good luck.

Blessed be!

Pappy

----------

## cach0rr0

shot in the dark here

i would wager your database isnt quite as repaired as you'd hoped 

disclaimer - most of my database knowledge is mssql, dont know how much that applies here

with mssql, power outages are a common cause of the dreaded 'torn page' - something which is largely unrecoverable. 

in your case, if you look at line 178, there's a $language variable. 

Presumably the language is pulled from a database of some form via a standard SELECT. 

As i dont know what app this is, i can only speculate - but i would highly suggest you try to identify which table holds the language settings (for most it's a blah_prefs, just from what ive seen), connect up via mysql from the command line using the same user your PHP application uses (e.g. mysql -u someuser -p), and see if you can do any actual SELECT's and whatnot from the table. 

It could well be the case that a SELECT fails, leaving a variable NULL that's supposed to contain a string, so your pcre match against the NULL string fails. 

If all functions on your site that use the DB fail, it could even be the case that the user table in the standard 'mysql' database is hosed, so the user your php app is using doesnt even exist as far as mysql knows. USUALLY this will manifest itself in a far more obvious fashion; i say usually...i cant imagine it not manifesting itself as anything other than a 'failed to connect' if your mysql user doesnt exist. 

It may not even be as bad as all of this. This is just one of my zillion typical crackpot theories, but if true, one for which no amount of reinstallation will help, and one which will require further massaging of mysql.

----------

## mlnzigzag

i did all your steps until fourth.

i replaced an old mysql backup

i did as well with the /var/www/ folder

i did check everything is got the right permissions

unfortunately the error is still the same!

even with the presumably broken "actual" mysql/www folder the error is the same!

u may like to take a look at it, old backup of mysql/www actually up:

http://host1.merqurio.it/medicomd/

the mainfile.php lines are already in the thread

the user used by the php script is obviously got all the right permissions he needs to use the db

i'm almost out of my mind

phisical damages to the drive? the chipset of the machine should alert about that, but it doesn't.

i would really hate to cleanly reinstall everything, it would be the first time for me that i need to cleanly reinstall a linux box!    :Sad: 

 *pappy_mcfae wrote:*   

> As a matter of fact, I had one of my machines get messed up by a lightning-strike induced power failure. Here is what I did to get things back in order:
> 
> 1) recompile gcc to make sure it didn't get hurt.
> 
> 2) recompile the kernel, as it most likely did take a hit. 
> ...

 

----------

## cach0rr0

Just found this

https://bugs.gentoo.org/258149

Is pcre in your use flags? If so, take it out, and re-emerge php

I'm assuming that's what the commented out bits in the ebuild do

If not, go into the .ebuild for the version of php you have installed, then do

```

ebuild name.of.ebuild.file digest

```

and emerge that same version

----------

## mlnzigzag

i had pcre in my useflags

i recompiled php with -pcre, then restarted apache and mysql (not sure it was needed)

then i connected to the url of the post before:

Fatal error: Call to undefined function preg_match() in /var/www/localhost/htdocs/medicomd/mainfile.php on line 39

 :Crying or Very sad: 

thank you for your help mate

----------

## pappy_mcfae

At this point, you are probably best starting over. Since the pages are safe, the server on which they run is immaterial, as long as it does run. For now, you are dead in the water. You will never fully know if there is a hardware component to this unless you assure a stable OS. You won't have that until you start fresh, or find out you can't due to hardware issues.

I would advise that you make a stage4 backup when you get the machine back to running right. That way, all you have to do is expand the backup, and you have a ready-to-go machine. I've wiped this machine completely, and repartitioned and reinstalled everything from stage4 backups. I didn't lose anything on the Linux side, and only upset one program on the Vinderz side. That's pretty frickin' cool if you ask me.

Don't look at it as a horror. Look at it as an opportunity to install Gentoo again. I may be weird, but I kind of like installing Gentoo fresh. It's completely geek woody-worthy!

Blessed be!

Pappy

----------

## mlnzigzag

Any ideas?

```

host1 ~ # ebuild /var/db/pkg/dev-lang/php-5.2.10/php-5.2.10.ebuild digest

Appending /var/db/pkg to PORTDIR_OVERLAY...

Traceback (most recent call last):

  File "/usr/bin/ebuild", line 249, in <module>

    debug=debug, tree=mytree)

  File "//usr/lib/portage/pym/portage/__init__.py", line 6292, in doebuild

    alist = mydbapi.getFetchMap(mycpv, useflags=useflags,

AttributeError: 'vardbapi' object has no attribute 'getFetchMap'
```

Thanks a lot ppl

----------

## cach0rr0

should do the ebuild that's in /usr/portage

Not /var/db/whatever

and make a backup of the original ebuild in case you need to revert

----------

