Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /

Ok, here come the responses...

Jason Tishler wrote:
> Frank,
>
> On Fri, May 02, 2003 at 12:58:22PM -0400, Frank Seesink wrote:
>
>>Jason Tishler wrote:
>>...[snip]...
>>
>>>Please run the attached program under both the Frank and postgres
>>>user accounts to confirm or refute the above hypothesis and report
>>>back to the list.
>>
>>Confirmed. Here's the output run as both 'Frank' (the admin level
>>acct) and 'postgres':
>>______________________________________________________________________
>>Frank(at)SEESINK /tmp
>>$ ./cit
>>1892 = OpenSemaphore() succeeded
>>______________________________________________________________________
>>postgres(at)SEESINK /tmp
>>$ ./cit
>>OpenSemaphore() failed with last error = 2
>>______________________________________________________________________
>
>
> The above is very interesting. I expected cit to fail under postgres
> but not with a last error of 2:
>
> $ fgrep 2L /usr/include/w32api/winerror.h | head -1
> #define ERROR_FILE_NOT_FOUND 2L
>
> Actually, I expected a last error of 5:
>
> $ fgrep 5L /usr/include/w32api/winerror.h | head -1
> #define ERROR_ACCESS_DENIED 5L
>
> Hence, your problem appears to be more insidious than a simple
> permissions problem.
>
>
>>Note that if I shutdown CygIPC and run the command from 'Frank', the
>>results are identical to the 'postgres' results. So yes, indeed, it
>>looks as if to the 'postgres' user, CygIPC does not exist/is not
>>responding/cannot be accessed. Now the mother of all questions: why?
>>Why does it work for you and not for me in XP?
>
>
> I don't know. I appears that the semaphores created by ipc-daemon are
> not accessible by users other than Frank.
>
> I have another idea. Please download the handle utility from
> Sysinternals:
>
> http://www.sysinternals.com/ntw2k/freeware/handle.shtml
>
> run the following when ipc-daemon is running under LocalSystem:
>
> $ handle -a -p ipc-daemon | fgrep Multi
> d8: Semaphore \BaseNamedObjects\MultiSemCtl_
> dc: Semaphore \BaseNamedObjects\MultiSemSem_
> e0: Semaphore \BaseNamedObjects\MultiSemShm_
> e4: Semaphore \BaseNamedObjects\MultiSemMsg_
> e8: File C:\Cygwin\tmp\MultiFileSem
> f0: File C:\Cygwin\tmp\MultiFileShm
> f8: File C:\Cygwin\tmp\MultiFileMsg
>
> and post your results to the list.

Here you go, run as user 'Frank' (admin). If you need it run as
'postgres', let me know. Copied handle.exe into /tmp (i.e.,
C:\cygwin\tmp) so I could run within BASH shell. Also note I checked
the file permissions in /tmp, just to be sure all was as it should be
(all this was done, by the way, after once again removing CYGWIN=nontsec
environ var and rebooting, so it's as it was):
______________________________________________________________________
Frank(at)SEESINK /tmp
$ ./handle.exe -a -p ipc-daemon | fgrep Multi
d4: Semaphore \BaseNamedObjects\MultiSemCtl_
d8: Semaphore \BaseNamedObjects\MultiSemSem_
dc: Semaphore \BaseNamedObjects\MultiSemShm_
e0: Semaphore \BaseNamedObjects\MultiSemMsg_
e4: File C:\cygwin\tmp\MultiFileSem
ec: File C:\cygwin\tmp\MultiFileShm
f4: File C:\cygwin\tmp\MultiFileMsg

Frank(at)SEESINK /tmp
$ ls -al
total 4138
drwxrwxrwx+ 4 Frank Users 0 May 5 13:44 .
drwxrwx---+ 10 Frank Users 0 Apr 29 17:37 ..
-rw-rw-rw- 1 SYSTEM Administ 3916520 May 5 13:15 MultiFileMsg
-rw-rw-rw- 1 SYSTEM Administ 22032 May 5 13:15 MultiFileSem
-rw-rw-rw- 1 SYSTEM Administ 202768 May 5 13:15 MultiFileShm
-rwx------+ 1 Frank None 69632 Oct 16 2001 handle.exe
...
______________________________________________________________________

Quick note: Prior to rebooting, while CYGWIN=nontsec was still in
effect, I noticed that the /tmp/MultiFile* files were tagged as owned by
user 'Frank' as opposed to 'SYSTEM'. Group was set to 'Administ' in
both cases. I figured with nontsec, EVERYTHING just appears as being
owned by the currently logged in user. That's what I recall from older
Cygwin versions anyway (prior to ntsec being default). But thought I'd
mention it 'just in case.'

...
>>I can't think of any apps which would get in the way of this, but
>>then, I'm not 100% clear on how CygIPC is contacted.
>
>
> ipc-daemon is contacted by opening semaphores -- exactly how cit does
> it. If not, why would I ask you to run cit?

I guess I should have been more clear. As the idea of semaphores are
not inherent in NT as in Unix, I was referring more to the system calls
being made by apps in order to contact CygIPC itself.

I'm more used to TCP/IP interaction, where you bind to a TCP or UDP
port as a server, and a client contacts the server by IP and TCP/UDP
port number. However, semaphores are more an internal mechanism (like
BSD sockets).

Somehow when you compile cit.c, those OpenSemaphore() calls are able to
route thru the Windows NT system to CygIPC. Now I know Cygwin1.dll
plays a role in all this somewhere, but as I don't code down at that
level, I'm out of my depth. But somewhere along the way Cygwin1.dll is
a shimmy that gives NT a functionality that it doesn't have itself, and
as far as I know, DLLs are basically just libraries of functions.

But in the end,as far as NT is concerned, there are two
processes--CygIPC and the app that is trying to reach it
(ipctest/initdb/postgres/whatever). And yet those two processes need to
be able to interact with each other. That implies some pathway through
NT's internal messaging system. Whatever else happens, in the end you
have to use the underlying OS' IPC-like mechanisms, even if you're
building something like Cygwin.

Using TCP/IP speak, I was curious HOW, exactly, CygIPC sets itself to
'listen' and how apps like ipctest 'call' CygIPC. It's obviously NOT
via the TCP/IP stack, as postmaster in the end does when you use the
'-i' switch, otherwise I would be looking at things like port/address
blocking by firewalling software, etc. But these apps are using
whatever NT uses internally for IPC. I'm just wondering if somehow,
when CygIPC sets itself up to 'listen', it is restricted to contact by
'Frank' for some reason (though I can't imagine why that would be....by
users with 'Administrative' privileges I could see easier, but that
didn't work when I made 'postgres' a member, so...)

>>And as mentioned, I've tried running CygIPC AS user 'postgres', and
>>even that did not work.
>
>
> The above is truly amazing!

Tell me about it.