Skip site navigation (1) Skip section navigation (2)

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

From: Frank Seesink <frank(at)mail(dot)wvnet(dot)edu>
To: pgsql-cygwin(at)postgresql(dot)org
Subject: Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /
Date: 2003-05-05 18:15:51
Message-ID: 3EB6AA57.80405@mail.wvnet.edu (view raw or flat)
Thread:
Lists: pgsql-cygwin
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.


In response to

pgsql-cygwin by date

Next:From: Frank SeesinkDate: 2003-05-05 18:19:16
Subject: Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /
Previous:From: Jason TishlerDate: 2003-05-05 15:00:11
Subject: Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group