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
installed.
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.
--Miguel
--- 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.
then
#
# 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 @@
fi
echo
-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}" ]
then
if [ "$1" = upgrade ]
@@ -245,8 +249,7 @@
fi
# Just in case something is still running
- pid=`ps ax | grep postmaster | grep -v grep | awk '{print $1}'`
-
+ pid=`pidof postmaster`
if [ -n "${pid}" ]
then
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" ]
then
POSTGRES_HOME=/var/lib/postgres
fi
POSTGRES_DATA=/var/postgres/data
PGDEBUG=3
PGECHO=yes
PGALLOWTCPIP=yes
--- End /etc/postgresql/postmaster.init
Reply to: