[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

postgresql: postinst uses potato-specific ps option

Package: postgresql
Version: 6.5.3-22

Severity: important

This is a follow-up to a private email I sent to Oliver a week or so
ago.  I probably should have sent a bug report at the time as well;
here it is now.  

When installing postgresql on a slink machine, the preinst breaks
because the postgresql.preinst script uses a potato specific ps
option.  The --User option of ps isn't in procps version 1:1.2.9-3,
the slink version, so preinst breaks.  {I think this bug is new; the
earlier versions of postgresql.postinst didn't use this ps syntax, did
they?}  There is a test for a running postmaster that is used in
postgresql-dump (and which has been tested a number of times) that can
be used in place of the --User option of ps.  Basically, we should do
something like:
  if ps auxc | grep -s '^postgres ' | grep -sq ' postmaster *$'
instead of  
  if ps --User postgres | grep -v grep | grep -q postmaster 
  # version-specific ps option! 

Is this a bug worth fixing?  Well, it does seem like there might 
(barely) be time to squeeze it in before the third test cycle begins, 
so at least it's possible.  The consequences of the bug are that the 
last couple bits of postinst never get executed if the newer version 
of procps isn't installed: usecatupd isn't set if postmaster is 
running; the warning about postgresql-slink isn't printed; the 
symlink from /usr/doc to /usr/share/doc isn't created; and a warning
is printed to the user.

While this may not be the end of the world, it does mean that
virtually anybody upgrading postgresql from slink will get a broken
install.  Apt appears to order installation alphabetically when it
doesn't have a reason to do otherwise, and postgresql comes before
procps so the new ps is usually not installed when postgresql is

You could choose to downgrade the bug instead of fixing it, but the
fix is a straightforward application of the same bit of code used
elsewhere, and the bug is one that will appear to any slink user
upgrading postgresql, so I think it's probably better to fix it than
to ignore it.

One of the bugs that was fixed in postgresql-dump also appears in
preinst: The pid of a running postmaster isn't dealt with correctly;
it fails, for instance, if someone is running 'less postmaster.init'.

Patches (to the postinst and preinst scripts, not to the .in
templates) to fix both bugs follow.


--- postgresql.postinst Sun Jun  4 13:26:16 2000
+++ postgresql.postinst.maw     Sat Jul  1 09:42:52 2000
@@ -373,7 +373,13 @@
 # take a little nap while the postmaster sorts itself out
 sleep 5
 # Only do the next bit if the postmaster is running
-if ps --User postgres | grep -v grep | grep -q postmaster
+#if ps --User postgres | grep -v grep | grep -q postmaster
+#  This uses a version-specific option to ps that is not present in 
+#  the slink version, so use a generic ps option and parse it ourselves,
+#  similar to what is done in postgresql-dump.
+#  maw 7/1/00.
+if ps auxc | grep -s '^postgres ' | grep -qs ' postmaster *$' 
+# Don't use set +e ; x=`ps auxc ...` ; set -e because that turns off the set +e from above.
     # set usecatupd to false for all users except superusers

--- postgresql.preinst  Sun Jun  4 13:26:16 2000
+++ postgresql.preinst.maw      Sat Jul  1 10:02:56 2000
@@ -234,7 +234,11 @@
-pid=`ps ax | grep postmaster | grep -v grep | awk '{print $1}'`
+# pid=`ps ax | grep postmaster | grep -v grep | awk '{print $1}'`
+# This doesn't work in all circumstances, as was noted in an earlier bug regarding postgresql-dump. 
+# Here I use pidof instead of parsing the ps output, but either solution could work.
+# maw 7/1/00.
+pid=`pidof postmaster`
 if [ -n "${pid}" ]
     if [ "$1" = upgrade ]
@@ -245,8 +249,7 @@
     # Just in case something is still running
-    pid=`ps ax | grep postmaster | grep -v grep | awk '{print $1}'`
+    pid=`pidof postmaster`
     if [ -n "${pid}" ]
         echo Stopping postgresql postmaster \(not found by the init.d script\)

-- System Information
Debian Release: 2.1
Kernel Version: Linux emma 2.0.36 #1 Sun Aug 1 22:25:18 PDT 1999 i686 unknown

Versions of the packages postgresql depends on:
ii  libc6          2.1.3-8        GNU C Library: Shared libraries and Timezone
ii  libncurses5    5.0-6          Shared libraries for terminal handling
ii  libreadline4   4.1-1          GNU readline and history libraries, run-time
ii  libpgsql2      6.5.3-20       Shared library libpq.so.2 for PostgreSQL
ii  debianutils    1.13.3         Miscellaneous utilities specific to Debian.
ii  procps         2.0.6-5        The /proc file system utilities.
  {But the bug only appeared when I had procps version 1:1.2.9-3 installed.}
ii  postgresql-cli 6.5.3-20       Front-end programs for PostgreSQL
ii  procps         2.0.6-5        The /proc file system utilities.

--- Begin /etc/postgresql/postmaster.init (modified conffile)
POSTGRES_HOME=`grep '^postgres:' /etc/passwd | awk -F: '{print $6}' | head -1`
if [ -z "$POSTGRES_HOME" ]

--- End /etc/postgresql/postmaster.init

Reply to: