Blank HTML on all confluence pages, when applied the 9.4.2, 9.3.7, 9.2.11, 9.1.16 and/or 9.0.20 PostgreSQL updates

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Fisheye および Crucible は除く

問題

Confluence seems to start correctly with no errors and nothing is showing on the logs when trying to access the page


診断

環境

    • You're using PostgreSQL
    •  Applied the 9.4.2, 9.3.7, 9.2.11, 9.1.16 and/or 9.0.20 PostgreSQL updates
    .

Diagnostic Steps

  • The following appears in the PostgreSQL log pg_log


    Starting PostgreSQL 9.1 database server
    * The PostgreSQL server failed to start. Please check the log output:
    2015-05-26 03:27:20 UTC [331-1] LOG:  database system was interrupted; last known up at 2015-05-21 19:56:58 UTC
    2015-05-26 03:27:20 UTC [331-2] FATAL:  could not open file "/etc/ssl/certs/ssl-cert-snakeoil.pem": Permission denied
    2015-05-26 03:27:20 UTC [330-1] LOG:  startup process (PID 331) exited with exit code 1
    2015-05-26 03:27:20 UTC [330-2] LOG:  aborting startup due to startup process failure
    

原因

On May 22, 2015, the PostgreSQL project released a set of updates to all supported versions of PostgreSQL. One of the fixes included in this batch of updates forced fsyncing of all PostgreSQL files on a restart after a crash. This fix was added to prevent certain kinds of data corruption which can occur if a system hosting a database has several failures in a row.

Unfortunately, this fix causes issues with some users' PostgreSQL setups due to file permissions issues, which can cause PostgreSQL to refuse to restart after an unexpected shutdown, or when restoring from a binary backup (PITR).

This issue is slated to be fixed in the 2015-06-04 Update Release.

回避策

As a temporary workaround, change the permissions on any symlinked files to being writable by the Postgres user. For example, on Ubuntu, with PostgreSQL 9.1, the following should work:

Make sure these configuration files are symbolic links before executing these commands! If someone has customized the server.crt or server.key file, you can erase them by following these steps. It's a good idea to make a backup of the server.crt and server.key files before removing them.

(as root)
# go to PGDATA directory
cd /var/lib/postgresql/9.1/main 
ls -l server.crt server.key

# confirm both of those files are symbolic links
# to files in /etc/ssl before going further

# remove symlinks to SSL certs
rm server.crt
rm server.key 

# copy the SSL certs to the local directory
cp /etc/ssl/certs/ssl-cert-snakeoil.pem server.crt
cp /etc/ssl/private/ssl-cert-snakeoil.key server.key

# set permissions on ssl certs
# and postgres ownership on everything else
# just in case
chown postgres *
chmod 640 server.crt server.key

service postgresql start



You will need to adapt the above example to your specific circumstances, but that should give you a general idea of what to do. The requirement is that the postgres user must have write access to everything in PGDATA or symlinked from PGDATA.

ソリューション

The PostgreSQL project expects to release another update very soon which addresses the file permissions issue. The expected release date for this update is June 4.

https://wiki.postgresql.org/wiki/May_2015_Fsync_Permissions_Bug

最終更新日 2018 年 11 月 14 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.