0

I have a build of PostgreSQL's Initdb utility that was compiled and linked on a remote build server running Fedora. On my system (Ubuntu 13.04 64-bit) when the utility is run using the command initdb -D /home/me/postgres_files/ -L /home/me/postgres_init_files/ the following is returned:

initdb: could not obtain information about current user: Success

This does not occur if I build the utility locally, only with a remote build from our build farm. I have so far managed to track the issue down to the following piece of code in initdb.c:

pw = getpwuid(geteuid());
if (!pw)
{
    fprintf(stderr,
          _("%s: could not obtain information about current user: %s\n"),
            progname, strerror(errno));
    exit(1);
}

It would seem that either the call to geteuid() or getpwuid() is failing, but errno is not being set by the failing function. Unfortunately I can't easily go in and debug the utility directly as this only occurs on a remotely build version of the utility!

I would be greatly appreciative if anyone could shed some light on this.

Thanks.

Pete
  • 62
  • 4
  • 1
    From a cursory look at the code (https://github.com/postgres/postgres/blob/master/src/bin/initdb/initdb.c), it would seem that it's not threaded. – Pete Sep 16 '13 at 16:19

1 Answers1

1

Referring the "inconsistent" error message:

If getpwuid() returns NULL, this not necessarilly needs to inidicate an error.

From man getpwuid (italic emphasis by me):

The getpwuid() function returns a pointer to a structure containing the broken-out fields of the record in the password database that matches the user ID uid.

[...]

The getpwnam() and getpwuid() functions return a pointer to a passwd structure, or NULL if the matching entry is not found or an error occurs.

From the fact that errno seems to be 0 anf those two statments above I'd conclude that the result of geteuid() simply could not be found by getpwuid().

Community
  • 1
  • 1
alk
  • 69,737
  • 10
  • 105
  • 255
  • 1
    Further under errors it lists: *"**0** or ENOENT or ESRCH or EBADF or EPERM or ... : The given name or uid was not found"* making this somewhat implementation dependent -- you may ENOENT one place and 0 another. – CodeClown42 Sep 16 '13 at 16:17
  • I see this, but why would this work on a locally built copy, and not on a remotely built one. We use a runtime that is built up completely from source and should be identical on every system, so it's unlikely to be due to different system libraries. Additonally, geteuid() simply returns the user ID of the calling process - why would a subsequent call to getpwuid() using the returned value fail? – Pete Sep 16 '13 at 16:22
  • @Pete: My answer was referring to the inconsistency of the error message as per the title of your question. Regarding the root cause for `getpwuid()` returning `NULL` I actually have no idea but could only guess: Do the both builds use the same libc? – alk Sep 16 '13 at 16:42
  • It might have been intercepted by SE-linux ? – joop Sep 16 '13 at 16:46