Bug 846631
| Summary: | Postgresql fail to start on RHEL 5.8 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Daniel Horák <dahorak> | ||||
| Component: | sudo | Assignee: | Daniel Kopeček <dkopecek> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Zbysek MRAZ <zmraz> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 5.8 | CC: | bugzilla, dapospis, dkopecek, ebenes, erinn.looneytriggs, j.k.vanamerongen, jlieskov, jpazdziora, ksrot, leonard-rh-bugzilla, lmiksik, mario.mikocevic, matt, mishu, mvadkert, pvrabec, redhat, rwf, sgraf, tgl, tmckay, ykinoshi | ||||
| Target Milestone: | rc | Keywords: | Regression, ZStream | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-01-08 07:50:00 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 435010, 846974 | ||||||
| Attachments: |
|
||||||
It's look like the problem is related to sudo-1.7.2p1-14.el5_8.2. With sudo-1.7.2p1-13.el5.x86_64 it works properly, when i update it to sudo-1.7.2p1-14.el5_8.2, it fails. This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. I can't reproduce that on CentOS 5: # cat /etc/redhat-release CentOS release 5.8 (Final) # yum install postgresql-server # service postgresql start Initializing database: [ OK ] Starting postgresql service: [ OK ] # rpm -q sudo sudo-1.7.2p1-14.el5_8.2 I don't think this is related to sudo. How could it? Looks more like a name resolution issue, perhaps http://www.question-defense.com/2009/09/17/log-could-not-translate-host-name-localhost-service-5432-to-address-name-or-service-not-known ? Are you sure sudo was the only package updated? (Product management seems a bit rash to discard this assuming postgres really wouldn't start because of a bug...) I tried it again with following steps and from my point of view it's look like it is somehow related to sudo, but I don't know how:
1. install fresh RHEL 5.8
2. register it to RHN
3. update all packages except sudo (sudo remain in version 1.7.2p1-13.el5)
# yum update --exclude=sudo
4. install postgresql-server
# yum install postgresql-server
5. try to start postgresql => succeed
# service postgresql start
Initializing database: [ OK ]
Starting postgresql service: [ OK ]
# service postgresql restart
Stopping postgresql service: [ OK ]
Starting postgresql service: [ OK ]
# service postgresql stop
Stopping postgresql service: [ OK ]
6. update sudo
# yum update
... truncated ...
Skipping security plugin, no data
--> Running transaction check
---> Package sudo.i386 0:1.7.2p1-14.el5_8.2 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================
Package Arch Version Repository Size
=============================================================
Updating:
sudo i386 1.7.2p1-14.el5_8.2 rhel-i386-server-5 352 k
Transaction Summary
=============================================================
Install 0 Package(s)
Upgrade 1 Package(s)
Total size: 352 k
Is this ok [y/N]: y
... truncated ...
Updated:
sudo.i386 0:1.7.2p1-14.el5_8.2
Complete!
7. try to start postgresql => fail
# service postgresql start
Starting postgresql service: [FAILED]
# tail -3 /var/lib/pgsql/pgstartup.log
LOG: could not translate host name "localhost", service "5432" to address: Name or service not known
WARNING: could not create listen socket for "localhost"
FATAL: could not create any TCP/IP sockets
Problem is with regular permissions for /etc/nsswitch.conf (thanks Trevor). # ls -l /etc/nsswitch.conf -rw------- 1 root root 1717 Aug 8 13:45 /etc/nsswitch.conf Investigating where its happened. Smoking gun? /etc/nsswitch.conf permissions changed by update to sudo-1.7.2p1-14.el5_8.2 This is a cleanly installed RHEL 8 machine root@blah:~# lsb_release -ir Distributor ID: RedHatEnterpriseServer Release: 5.8 Last login: Wed Aug 8 14:47:01 2012 from blah root@blah:~# ls -l /etc/nsswitch.conf -rw-r--r-- 1 root root 1716 Aug 8 14:42 /etc/nsswitch.conf root@blah:~# rpm -q sudo sudo-1.7.2p1-13.el5.i386 root@blah:~# root@blah:~# root@blah:~# yum update sudo <snip> --> Running transaction check ---> Package sudo.i386 0:1.7.2p1-14.el5_8.2 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================= Package Arch Version Repository Size ============================================================================================================================= Updating: sudo i386 1.7.2p1-14.el5_8.2 rhel-i386-server-5 352 k Transaction Summary ============================================================================================================================= Install 0 Package(s) Upgrade 1 Package(s) Total download size: 352 k Is this ok [y/N]: y Downloading Packages: sudo-1.7.2p1-14.el5_8.2.i386.rpm | 352 kB 00:00 <snip, import a gpg key> Is this ok [y/N]: y Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : sudo 1/2 Cleanup : sudo 2/2 Installed products updated. Updated: sudo.i386 0:1.7.2p1-14.el5_8.2 Complete! root@blah:~# ls -l /etc/nsswitch.conf -rw------- 1 root root 1717 Aug 8 14:53 /etc/nsswitch.conf Is it maybe because mktemp creates a file with permissions 600 (rw by owner) ? In view of comment #6, reassigning to sudo. (Or could it be a yum or rpm bug?) I hadn't realized the recreation of nsswitch.conf is conditional. As there's no "sudoers" line in it on my system the file permissions survive here, which is why I couldn't reproduce the issue. Seems this package is jinxed ;) First the selinux permissions twice, now this. I reckon all maintainers are being instructed to watch the updates they produce for file and selinux permission side effects? Now I regret that I didn't use sed -i... I'll fix this ASAP. *** Bug 846764 has been marked as a duplicate of this bug. *** *** Bug 846947 has been marked as a duplicate of this bug. *** *** Bug 846953 has been marked as a duplicate of this bug. *** This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. *** Bug 846772 has been marked as a duplicate of this bug. *** Why is PM repeatedly telling us this issue will not be addressed? Afaict this is a blocker. Created attachment 603230 [details]
proposed sudo.spec changes
(In reply to comment #18) > Why is PM repeatedly telling us this issue will not be addressed? Afaict > this is a blocker. It's just a bot. We've got the necessary flags now. For the casual visitor that is looking for a solution for their problem after having installed this update: # chmod 644 /etc/nsswitch.conf should fix things. (In reply to comment #19) > Created attachment 603230 [details] > proposed sudo.spec changes Why are these scripts still making unnecessary changes to nsswitch.conf? This is attempting to fix one of the issues and ignoring the rest. Please take another look at the versions provided in bug 846764. according to a recent errata this is now fixed with sudo-1.7.2p1-14.el5_8.3 if I'm right. Please see: http://rhn.redhat.com/errata/RHBA-2012-1160.html *** Bug 847235 has been marked as a duplicate of this bug. *** (In reply to comment #24) > according to a recent errata this is now fixed with sudo-1.7.2p1-14.el5_8.3 > if I'm right. Please see: > http://rhn.redhat.com/errata/RHBA-2012-1160.html Releasing an RHBA to correct an issue introduced by an RHSA presents a secondary problem for our environment, and probably others (judging from discussions on the satellite and spacewalk lists). We are required by SLAs to apply RHSA errata on a controlled QA-then-prod basis. Updates for non-security errata are done ad hoc by package, so those errata are not cloned into our patch channels (although the packages are). So the regression introduced by the RHSA would be corrected only by specific package update rather than in the course of our patch cycle. Although making this correction an RHBA appears to conform to RH errata policy, I'm bringing this up for consideration of whether that's the right thing to do. (In reply to comment #27) > Although making this correction an RHBA appears to conform to RH errata > policy, I'm bringing this up for consideration of whether that's the right > thing to do. Hello, thank you for your feedback. Yes, issuing a correction for a non-security regression, found in security (RHSA) advisory, later via bug-fix (RHBA) advisory is in conformity with Red Hat policy (since security advisories can not contain corrections for non-security problems). Would the regression be of security nature (IOW it would be the new security flaw due incorrect fix for previous issue), that would be corrected via another / new security advisory. Hope the above being helpful. Let us know if we can be of any further assistance. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team (In reply to comment #28) Thanks, Jan. In my view the regression causes a DOS, and is thus security related, but I'm not going to belabor it further. I've warned my team about the issue and what to do on an ad hoc basis. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0112.html |
Description of problem: Postgresql fails to start on RHEL 5.8. Version-Release number of selected component (if applicable): postgresql-server-8.1.23-5.el5_8.i386 How reproducible: 100% Steps to Reproduce: 1. Install RHEL 5.8, register it to RHN 2. Install postgresql-server # yum install postgresql-server 3. Try to start postgres # service postgresql start 4. # tail -F /var/lib/pgsql/pgstartup.log Actual results: Initializing database: [ OK ] Starting postgresql service: [FAILED] ... LOG: could not translate host name "localhost", service "5432" to address: Name or service not known WARNING: could not create listen socket for "localhost" FATAL: could not create any TCP/IP sockets ... Expected results: Initializing database: [ OK ] Starting postgresql service: [ OK ] Additional info: Setting SELinux to permissive mode have no effect. Note also that resolving localhost works with other programs, like ping: # ping localhost PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.160 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.045 ms It is similar to Bug 818585 - but it's look like it isn't related to SELinux.