Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 / - Mailing list pgsql-cygwin

From Frank Seesink
Subject Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /
Date
Msg-id b8u645$129$1@main.gmane.org
Whole thread Raw
In response to Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /  (Jason Tishler <jason@tishler.net>)
Responses Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /
List pgsql-cygwin
Jason Tishler wrote:
...[snip]...
> Your strace (i.e., ipctest-frank.log) yields the following:
>
>     $ fgrep 'errno 88' ipctest-frank.log
>        67   46182 [main] ... writev: 27 = write (1, 0x22FBA0, 1), errno 88
>        53   46505 [main] ... writev: 7 = write (2, 0x22FBA0, 1), errno 88
>        58   46837 [main] ... writev: 2 = write (2, 0x22FBA0, 1), errno 88
>        60   47264 [main] ... writev: 24 = write (2, 0x22FBA0, 1), errno 88
>        53   47586 [main] ... writev: 1 = write (2, 0x22FBE0, 1), errno 88
>
> My strace with ipc-daemon running yields the following:
>
>     $ ps -ef | fgrep ipc-daemon
>       system    2264       1   ?  07:29:28 /usr/local/bin/ipc-daemon
>     $ strace ipctest s | fgrep 'errno 88'
>     $
>
> My strace without ipc-daemon running yields the following:
>
>     $ ps -ef | fgrep ipc-daemon
>     $ strace ipctest s 2>/dev/null | fgrep 'errno 88'
>       152   37428 [main] ... writev: 7 = write (2, 0x22FBA0, 1), errno 88
>        76   37739 [main] ... writev: 2 = write (2, 0x22FBA0, 1), errno 88
>        75   38151 [main] ... writev: 24 = write (2, 0x22FBA0, 1), errno 88
>       106   38485 [main] ... writev: 1 = write (2, 0x22FBE0, 1), errno 88
>        75   38799 [main] ... writev: 38 = write (1, 0x22FE18, 1), errno 88
>
> Hence, your strace is very similar to what I get when ipc-daemon is
> *not* running.

    That seems reasonable.  The impression I get is that running as user
'postgres' programs don't 'see' the CygIPC daemon.  But I can't figure
out why.  And since you mentioned in another post that you've had it
working just fine, it makes me wonder what, if anything, I've done on
these XP installs that would 'block' that ability.  (I tend to harden
boxes I setup...comes with the territory...but sometimes the measures we
take to protect a Windows box inadvertently breaks a feature we need.  I
just wish I could figure out what that was.)

> My WAG from the above is that for some reason the following cygipc code
> is failing on your XP Pro SP1 setup:
>
> static int IsGSemSemExist()
> {
>     GSemSem = OpenSemaphore(SEMAPHORE_ALL_ACCESS, FALSE, CYGWIN_IPCNT_SEMSEM);
>     if( GSemSem != NULL )
>     {
>         return (1) ;
>     } else {
>         return (0) ;
>     }
> }

    Again, sounds about right.  As user 'postgres', initdb cannot seem to
see the IPC daemon, so this function returning 0 makes sense.

> 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.

    FYI:  Your .EXE was ripped out by an email virusscanner it appears
(either ours or Gmane's...can't tell which), and I have the following
warning at the head of your email:

    Warning: This message has had one or more attachments removed
    Warning: (cit.exe).
    Warning: Please read the "VirusWarning.txt" attachment(s) for more
information.

So what's involved in compiling this code?  Just straightforward 'gcc -o
cit.exe cit.c' ?  Forgive my being just a tad leary.  I'm sure the code
is legit.  I just figured I'd ask first to verify that you did send me
an .EXE. :-)

> BTW, I just thought of a potential workaround.  What happens if you run
> ipc-daemon under the postgres account.  Does "ipctest s" under postgres
> work?  Does initdb work?  Remember to delete the /tmp files created by
> ipc-daemon before trying.

    Actually, if you read my posts from last night, you'll see I've already
covered that ground...and then some.  (Heck, 'postgres' wouldn't work
when I made it an Administrator account!!!)  Not sure why it's being
such a pain under XP.

    Do you happen to know what default security changes MS may have made in
XP, say in the 'Local Security Policies', between 2000 & XP?  I know of
a few, but none really apply.  And I've tried changing quite a few that
I thought in some bizarre way might play a role, but have had no luck so
far.


pgsql-cygwin by date:

Previous
From: Jason Tishler
Date:
Subject: Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /
Next
From: Jason Tishler
Date:
Subject: Re: Hi