RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 847357 - Postgres startup script disregards /var/lib/pgsql/data/postgresql.conf TCP settings
Summary: Postgres startup script disregards /var/lib/pgsql/data/postgresql.conf TCP se...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: postgresql
Version: 6.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-10 17:13 UTC by Dmitry S. Makovey
Modified: 2013-07-03 03:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-10 19:15:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dmitry S. Makovey 2012-08-10 17:13:13 UTC
Description of problem:

configuring PostgreSQL on RHEL6 platform we needed to change default port on which PostgreSQL listens from 5432 to 15432. Changing /var/lib/pgsql/data/postgresql.conf didn't yield desired results as postgres daemon kept on listenting on 5432 port.

Looking closer at init script it seems like things were geared towards running several instances. Which is fine, but you don't have to control ports at that level as it's enough to control PGDATA and everything else can be controlled from "normal" postgresql.conf. 

Version-Release number of selected component (if applicable):

# rpm -q postgresql
postgresql-8.4.11-1.el6_2.x86_64

How reproducible:

always

Steps to Reproduce:
1. service postgresql stop
2. uncomment and change connection settings in /var/lib/pgsql/data/postgresql.conf :

listen_addresses = 'localhost'
port = 15432                  

3. service postgresql start
  
Actual results:

postgresql listening on port 5432

Expected results:

postgresql listenting on port 15432

Additional info:

Things may be fixed by *not* supplying PGPORT portion to postmaster invocation in cases where "grep -qe '^\s*port\s*=' $PGDATA/postgresql.conf" yields positive result.

As a matter of fact PGDATA can also be overridden in postgresql.conf file...

Comment 2 Dmitry S. Makovey 2012-08-10 17:26:15 UTC
as a side-note: moving postgresql to a different port number also triggers SELinux denial which could be resolved with:

#============= postgresql_t ==============
allow postgresql_t port_t:tcp_socket name_bind;

Since postgresql in RHEL6 seems to be geared for multi-DB setups, it may be better to have SELinux tunable for the above rule. I found allow_user_postgresql_connect which is one tunable to enable connection *to* postgreSQL process, but there needs to be another one to allow postgreSQL bind to an arbitrary port?

Comment 3 Tom Lane 2012-08-10 19:05:01 UTC
This is not a bug.  It has always been the case that the port number (like PGDATA) has to be configured in the init script if you want to change it.  Changing it in postgresql.conf won't work reliably because pg_ctl has to know it.

I will agree that this fact is underdocumented :-(

Comment 4 RHEL Program Management 2012-08-10 19:15:11 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 5 Dmitry S. Makovey 2012-08-10 20:36:56 UTC
should I open a separate bug for comment #2 then, as it seems that only first comment was addressed in reply?

Comment 6 Tom Lane 2012-08-10 22:19:23 UTC
That would be something to discuss with the selinux-policy people, not me.  I think it's a questionable thing anyway whether selinux-policy should support nonstandard configurations out-of-the-box ... who's to say whether postgres connecting to an unusual port isn't something selinux *ought* to complain about?

Comment 7 Tom Lane 2012-08-17 17:05:52 UTC
With respect to the SELinux configuration issue, I've added the following text to the README.rpm-dist doc file for postgresql:

If you are running SELinux in enforcing mode (which is highly recommended,
particularly for network-exposed services like PostgreSQL) you will need to
adjust SELinux policy to allow the postmaster to use non-default PGPORT or
PGDATA settings.  To allow use of a non-default port, say 5433, do this
as root:
    semanage port -a -t postgresql_port_t -p tcp 5433
To allow use of a non-default data directory, say /special/pgdata, do:
    semanage fcontext -a -t postgresql_db_t "/special/pgdata(/.*)?"
If you already created the directory, follow that with:
    restorecon -R /special/pgdata
These settings are persistent across reboots.  For more information
see "man semanage".

(This is only in the Fedora copy at the moment, but it will propagate into RHEL in due time.)


Note You need to log in before you can comment on or make changes to this bug.