Hi Vincent, thanks a lot for your detailled analysis and feedback. Indeed this helps to narrow down the problem.
Vincent McIntyre [2007-07-17 14:13 +1000]: > The root cause in my case was the existing database was owned by a > UID that was in NIS. During the upgrade another 'postgres' UID was > created, in /etc/passwd, and this UID was not able to access the > directory /var/lib/postgresql/8.1/main Ah, that would indeed be it. I wonder whether there is a cleaner solution for that. , which has permissions 0700 > But is it worth adding a check to the startup scripts that tests > whether the postgres instance directory (/var/lib/postgresql/8.1/main) > is owned by the correct UID, and if not send a warning to the postgres logs > or maybe to syslog? A check like this in the init script would have made it > easier to find the issue. > [...] > Stopping PostgreSQL 8.1 database server: main Error: The cluster is owned > by user id 93 which does not exist any more > failed! This warning already exists in that form (the postinst/postrm just call the init script). What do you think should be changed here? I can add an extra warning to the syslog if that helps, but my gut feeling is that syslog wouldn't be the first place people look at after a failed upgrade (screen output is usually much more helpful). > However in my case just rerunning the dist-upgrade (with the machine > running at runlevel 2) did not work. > Neither did removing and reinstalling. (I did not 'purge'.) > This is where I thnk there may a remaining problem. > > # apt-get remove postgresql-8.1 > (worked ok) This does not actually remove the existing instance in /var/lib/postgresql/, though. It would be very evil if that happened. It is done on purge, though, so purging the package should work. > I can't find a config file that mentions server.key This is an implicit default in postmaster itself. I'm glad that you could recover the installation. However, I'm unsure how to proceed with this bug. Playing dirty tricks wit chown during install/upgrade seems really evil to me, I will not open a can of worms like that. A reasonable thing would be to not have the package installation fail when the existing cluster is not accessible, and just let it go on and have the admin fix it later. Would that be reasonable for you, too? Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
