[support] Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work - continuing

[Jamie Holly]

Watchdog won't have anything in it if Drupal can't connect to the 
database.  Why don't you take the $db_url from the settings.php file of 
one of the Drupal installations you have already done and put in in the 
troubled installation, changing just the database name to the 
appropriate one (ie: keep the user:password at host the same and just 
change the /databasename). As long as that user has access to the 
database you are trying to use, everything should be fine.

Jamie Holly
http://www.intoxination.net
http://www.hollyit.net

On 3/25/2013 6:55 PM, Max Pyziur wrote:
>
> On Mon, 25 Mar 2013, Metzler, David wrote:
>
> > I have seen other threads on this error that suggest looking at the watchdog table, which might be filling up with errors ( via a select * from watchdog).  You might try deleting all the records in watchdog, visiting the site then looking at watchdog again to see what info is in there.
>
> The only thing that is showing up in watchdog is information from cron
> jobs running.
>
> > This isn't a civicrm installation is it?
>
> Don't know; what's civicrm?
>
> > Looks like you've got a thorny one....
>
> Things are starting to point to there being an  authentication problem.
>
> Now, I'm wondering if it isn't PHP and one of its setting being different
> from CentOS 5/PHP5.1 and CentOS 6/PHP5.3.
>
> Is there a HowTo for deconstructing Drupal's authentication process?
>
> Something like, start at ~/index.php, go to includes/bootstrap.inc, etc?
>
> > Dave
>
> Max
>
> >
> > -----Original Message-----
> > From: support-bounces at drupal.org [mailto:support-bounces at drupal.org] On Behalf Of Max Pyziur
> > Sent: Monday, March 25, 2013 1:25 PM
> > To: support at drupal.org
> > Cc: Earnie Boyd
> > Subject: Re: [support] Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work - continuing
> >
> >
> >
> > On Mon, 25 Mar 2013, Max Pyziur wrote:
> >
> >> On Mon, 25 Mar 2013, Earnie Boyd wrote:
> >>
> >>> Ensure you empty any table with cache* as well as sessions table.
> >>
> >> I take it you mean running a script like this:
> >> DELETE FROM cache WHERE 1=1;
> >> DELETE FROM cache_block WHERE 1=1;
> >> DELETE FROM cache_filter WHERE 1=1;
> >> DELETE FROM cache_form WHERE 1=1;
> >> DELETE FROM cache_menu WHERE 1=1;
> >> DELETE FROM cache_page WHERE 1=1;
> >> DELETE FROM cache_update  WHERE 1=1;
> >>
> >> DELETE FROM sessions  WHERE 1=1;
> >>
> >> (1=1 is a kluge I used when I worked on Informix databases; probably
> >> unnecessary these days).
> >>
> >> Thanks.
> >
> > I tried this procedure on one site, and it still fails to remove the 503
> > error.
> >
> > However, this does seem to be the correct area (stored data) to remedy
> > this.
> >
> > New Drupal installs of 6.14 to 6.28 on Postgresql 8.4/PHP 5.3 do
> > work/function.
> >
> > So it isn't the software (PHP and Postgresql), it points to the data.
> >
> >> Max Pyziur
> >> pyz at brama.com
> > [... recycle ...]
> >
> >
> >>> Earnie
> >>>
> >>> On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz at brama.com> wrote:
> >>>>
> >>>>
> >>>> On Sun, 24 Mar 2013, Jamie Holly wrote:
> >>
> >> [... delete for the sake of brevity ...]
> >> --
> >> [ Drupal support list | http://lists.drupal.org/ ]
> >>
> > --
> > [ Drupal support list | http://lists.drupal.org/ ]
> > --
> > [ Drupal support list | http://lists.drupal.org/ ]
> >