[CDash] CDash 2.0.2/PostgreSQL from Ubuntu 15.10 to 16.04

Fri Apr 29 03:01:29 UTC 2016

Good news! I have been able to get my postgresql database working again.
Now my CDash is back and fully functional.

In short, I installed CDash and postgresql years back when the postgresql
version was 9.1. Since then, I upgraded my Ubuntu server at every release
(6-month). I ended up with 4 different versions of postgresql installed on
Ubuntu 16.04: 9.1, 9.3, 9.4 and 9.5.

My database was on the 9.1 version (in /var/lib/postgresql/9.1/main). I
just had to uninstall the packages for 9.3 and 9.4 to make it work again.
(I kept 9.5 as it is the current version for Ubuntu 16.04 and I may try to
migrate my database from 9.1 to 9.5 in the near future). Unfortunately, I
don't know why it worked.

Here are some details of my investigation for future users browsing the
cdash archive and facing a similar issue:

1. Looking at the running processes with "ps aux | grep postgres", I could
see that only 9.3, 9.4 and 9.5 postgres were running, but not 9.1.
2. I first suspected that 9.1 was not supported by the new systemd.
However, "systemctl status" confirmed that there was a failed unit and
"systemctl --failed" showed that 9.1 was the failed unit. The report showed
that 9.1 was loaded but not started properly. At least, it meant that
systemd was supporting 9.1
3. I tried to look at the systemd log with "journalctl -b" but there was no
useful information about the failure, I also looked at the log of
postgresql itself but because it was not started properly there was no
information in /var/log/postgresql/postgresql-9.1-main.log
4. I tried to change the debug level for postgresql 9.1 by adding the
following line to /etc/postgresql/9.1/main/postgresql.conf:
log_statement = 'all'
5. I rebooted. Still got nothing in the postgresql log
6. I tried to start 9.1 manually (through systemd) and... it worked!
(systemctl start postgresql at 9.1-main.service)
7. At this point, it meant that something prevented to start 9.1 only at
boot time. I thought it was either a permission issue (but I did not find
any) or a bad systemd dependency (the fact that I could start the service
after booting meant that the dependency could have been resolved later on).
But with no helpful log, I did not know what to add in front of "Wants=" in
/etc/systemd/system/multi-user.target.wants/postgresql.service

8. This is the lucky step: I figured out that I did not need 9.3 and 9.4
anyway so I decided to remove the matching packages
(postgresql-client-9.3,postgresql-9.3, postgresql-client9.4, postgresql-9.4
and postgresql-contrib-9.4)
9. For a reason I don't understand, after a new reboot 9.1 started
successfully.

--
François Bertel

On Tue, Apr 26, 2016 at 10:02 PM, François Bertel <fbopensource at gmail.com>
wrote:

> It happened that there was already a test.php at /var/www doing exactly
> that (ie calling phpinfo(); ) At first, the rendered page was blank, which
> indicated that php was not working properly, as you suggested.
>
>
> I think the issue originates from the instructions on the CDash wiki page
> about Ubuntu 12.04:
>
> $ sudo apt-get install apache2 mysql-server php5 php5-mysql php5-xsl php5-curl php5-gd
>
> The line above installs for an explicit version of the php packages: php5 (maybe at the time of Ubuntu 12.04 there was no version-neutral "php" package mechanism, who knows) With the upgrade to 16.04, which switched to php7 as the default, somehow the installation became incomplete.
>
>
> In order to solve the issue, I tried to install the packages with
> version-neutral php names:
>
>
> $ sudo apt-get install php libapache2-mod-php php-gd php-curl php-pgsql
> The following additional packages will be installed:
>   php7.0 php7.0-fpm libapache2-mod-php7.0 php7.0-curl php7.0-gd
> php7.0-pgsql
> The following NEW packages will be installed:
>   php php7.0 php7.0-fpm libapache2-mod-php libapache2-mod-php7.0 php-curl
> php-gd php7.0-curl php7.0-gd php-pgsql php7.0-pgsql
>
> After restarting apache (sudo service apache2 restart), I was able to see
> the correct phpinfo page.
>
>
> Going back to the CDash index page itself, I was able to see a correctly
> rendered CDash page. Unfortunately right now I see the CDash install page
> because cdash is unable to access the postgresql db. This is probably
> another package issue that I still have to investigate.
>
>
> Thanks again for the diagnostic trick with phpinfo.
>
> --
> François Bertel
>
> On Mon, Apr 25, 2016 at 7:45 PM, François Bertel <fbopensource at gmail.com>
> wrote:
>
>> Thanks Zack. I will get back to you when I have some relevant progress to
>> report.
>>
>> --
>> François Bertel
>>
>>
>> On Mon, Apr 25, 2016 at 12:27 PM, Zack Galbreath <
>> zack.galbreath at kitware.com> wrote:
>>
>>> Hi Francois,
>>>
>>> On Sat, Apr 23, 2016 at 11:01 AM, Francois Bertel <
>>> fbopensource at gmail.com> wrote:
>>>
>>>> I had CDash 2.0.2 successfully working on Ubuntu 15.10, using a
>>>> PostgreSQL database.
>>>>
>>>>
>>>> I just upgraded to Ubuntu 16.04 and now when I go to my main CDash page
>>>> (http://<myhostname>.local/CDash/), the output looks like some code
>>>> that was not executed and passed directly to the client instead:
>>>>
>>>> the title of the page is ".$CDASH_MAININDEX_TITLE."
>>>>
>>>> the page itself starts with:
>>>>
>>>> '; $xml .= add_XML_value("title","CDash"); $xml .=
>>>> "".$CDASH_CSS_FILE.""; $xml .= "".$CDASH_VERSION.""; $Banner = new Banner;
>>>> $Banner->SetProjectId(0); $text = $Banner->GetText(); if($text !== false) {
>>>> $xml .= ""; $xml .= add_XML_value("text",$text); $xml .= ""; } $xml .=
>>>> "".$_SERVER['SERVER_NAME'].""; $xml .= "".date("r").""; // Check if the
>>>> database is up to date if(!pdo_query("SELECT updateid FROM build2update
>>>> LIMIT 1") ) { $xml .= "1"; } $xml .= "
>>>> [...]
>>>>
>>>> Do you know what could cause this behavior?
>>>>
>>>
>>>
>>> To me, this sounds like PHP is not being properly parsed by your web
>>> server.
>>>
>>> Try creating a .php page that just calls phpinfo() and navigate to it
>>> using your web browser.
>>>
>>> http://php.net/manual/en/function.phpinfo.php
>>>
>>> Let us know if this renders correctly or not.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20160428/227531f5/attachment-0001.htm>