Description of problem: It seems the user postgres is not created when installing postgresql* packages. [root@gruyere /var]# rpm -q postgresql-libs postgresql postgresql-libs-7.4.2-1 postgresql-7.4.2-1 [root@gruyere /var]# apt-get install postgresql-server Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed: postgresql-server (7.4.2-1) 0 upgraded, 1 newly installed, 0 removed and 0 not upgraded. Need to get 0B/3098kB of archives. After unpacking 7591kB of additional disk space will be used. Checking GPG signatures... Committing changes... Preparing... ########################################### [100%] chown: `postgres:postgres': invalid user 1:postgresql-server ########################################### [100%] warning: user postgres does not exist - using root warning: user postgres does not exist - using root warning: user postgres does not exist - using root warning: user postgres does not exist - using root Done. Version-Release number of selected component: postgresql-7.4.2-1
Hm, there is code in the server RPM specfile to create user postgres and group postgres if they do not already exist. Can you try these commands by hand (as root) and see what happens? groupadd -g 26 -o -r postgres useradd -M -n -g postgres -o -r -d /var/lib/pgsql -s /bin/bash \ -c "PostgreSQL Server" -u 26 postgres The specfile is set up to ignore any and all errors from these commands, which I suppose is meant to avoid failing if the user/group already exist, but I suspect it is masking some other problem that's specific to your installation.
[root@gruyere /var]# groupadd -g 26 -o -r postgres groupadd: group postgres exists zsh: exit 9 groupadd -g 26 -o -r postgres [root@gruyere /var]# useradd -M -n -g postgres -o -r -d /var/lib/pgsql -s /bin/bash -c "PostgreSQL Server" -u 26 postgres [root@gruyere /var]# Group has been added by the package, the user hasnt. (note that rpm doesnt complain about the group) I can reproduce the problem with "rpm -e postgresql-server ; rpm -Uvh postgresql-server-7.4.2-1". After a little more investigation : the problem is not in postgresql, it's nscd. If i shutdown it, the problem is fixed. I think we can close as WORKSFORME.. or reassign it to the glibc.
Hmm ... [reads nscd man page] ... So the real issue is that the groupadd/useradd sequence is done by the script fast enough that the group name is not visible through the nscd cache at the time useradd runs, causing useradd to fail. Even if useradd were to be hacked to succeed, the subsequent chown would probably come along before nscd times out and updates its cache. One would think this happens for every RPM that tries to create a new user/group, not just Postgres. The only Postgres-level solution I can see is to put a couple of "sleep 15" delays into the RPM's preinstall script, which I'm not willing to do. My thought is that nscd is fundamentally broken if it doesn't watch for updates to the underlying files, rather than rely on a timeout. I'm gonna cc the nscd maintainer and see what he has to say. (I'd re-mark this as an nscd bug, except the popup list doesn't offer it as an option. Odd.)
See bug 125421.
I'm closing this bug entry, since bug 125421 against nscd seems to be where the problem really is. *** This bug has been marked as a duplicate of 125421 ***
...against shadow-utils, that is :)
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.