Re: postgres launch daemon not working

Hi Ryan,

On Jan 31, 2012, at 12:34 PM, Ryan Schmidt wrote:

> 
> On Jan 31, 2012, at 13:52, Scott Frankel wrote:
> 
>> Jan 31 08:26:02 tiento org.macports.postgresql84-server[1920]: server starting
>> Jan 31 08:29:07 tiento com.apple.SystemStarter[53]: Starting PostgreSQL database server
>> Jan 31 08:29:07 tiento com.apple.SystemStarter[53]: pg_ctl: could not open PID file
"/Library/PostgreSQL8/data/postmaster.pid": Permission denied
>> Jan 31 08:29:08 tiento SystemStarter[53]: PostgreSQL database server (90) did not complete successfully
>> 
>> 
>> Looks like pg_ctl is trying to open a postmaster.pid file it doesn't have permissions for.  How can I point
launchd invocations of pg_ctl to the correct postgres data dir?  I initialized my db according to info I
gleaned from searches; eg:
>> 
>> 	% sudo su postgres \ -c '/opt/local/lib/postgresql84/bin/initdb -D /opt/local/var/postgresql84/defaultdb'
>> 
>> 
>> Prior to that, I reinstated the postgres user name with:
>> 
>> 	% sudo dscl . -append /Users/postgres UniqueID 401
>> 
>> 
>> I assigned the postgres username to UID 401, as my previous installation's postgres files seemed to be
owned by user 401 of group postgres.  I wonder if this is the source of the permissions problem.
> 

Re: postgres launch daemon not working

Hi Daniel,

It works!  Details follow below.

On Jan 31, 2012, at 1:13 PM, Daniel J. Luke wrote:

> On Jan 31, 2012, at 2:52 PM, Scott Frankel wrote:
>> 	% sudo su postgres -c "/opt/local/lib/postgresql84/bin/pg_ctl -D
/opt/local/var/postgresql84/defaultdb -l
/opt/local/var/postgresql84/defaultdb/data/logfile.txt start"
> 
>> Jan 31 08:29:07 tiento com.apple.SystemStarter[53]: pg_ctl: could not open PID file
"/Library/PostgreSQL8/data/postmaster.pid": Permission denied
>> Jan 31 08:29:08 tiento SystemStarter[53]: PostgreSQL database server (90) did not complete successfully
> 
> This looks like you are pointing to a different directory than the one you set up when you installed
postgresql84-server (and also a different one than the one you're pointed to when you manually start
postgres). 

That's exactly what I was trying to explain in my last email.  I'm doing nothing explicit to point to the
/Library/PostgreSQL8/ directory.

>> Looks like pg_ctl is trying to open a postmaster.pid file it doesn't have permissions for.  How can I point
launchd invocations of pg_ctl to the correct postgres data dir?  
> 
> If you look at the plist that macports installed, you'll see that it uses a wrapper script to launch the
postgres server process. That script will default to using the environment variable $POSTGRESQL84DATA
for the data dir (and fall back on the one you show that you're using).
> 

Re: postgres launch daemon not working

On Tue, Jan 31, 2012 at 04:47:09PM -0800, Scott Frankel wrote:
> On Jan 31, 2012, at 12:34 PM, Ryan Schmidt wrote:
> > It should not have caused a problem, though it was also unnecessary to create your own postgres user,
since that (along with creating the server directories, and the launchd plist) is the purpose of
installing the postgresql*-server ports.
> 
> Good to know.  How would I have been able to find that out myself?  Knowing that ahead of time would've saved me
significant effort.

It probably wouldn't hurt if the postgresql*-server ports had a more
descriptive description...

Dan

--

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/

Re: postgres launch daemon not working

That'd be great!  Happy to contribute to the effort if I can.

Thanks
Scott

On Jan 31, 2012, at 7:13 PM, Dan Ports wrote:

> On Tue, Jan 31, 2012 at 04:47:09PM -0800, Scott Frankel wrote:
>> On Jan 31, 2012, at 12:34 PM, Ryan Schmidt wrote:
>>> It should not have caused a problem, though it was also unnecessary to create your own postgres user,
since that (along with creating the server directories, and the launchd plist) is the purpose of
installing the postgresql*-server ports.
>> 
>> Good to know.  How would I have been able to find that out myself?  Knowing that ahead of time would've saved
me significant effort.
> 
> It probably wouldn't hurt if the postgresql*-server ports had a more
> descriptive description...
> 
> Dan
> 
> -- 
> Dan R. K. Ports              MIT CSAIL                http://drkp.net/
> 

gcl fail

Hi, all.

I'm trying to install gcl on 10.6.8 & the tail of main.log is:

`:info:build unexmacosx.c:1400: warning: initialization from
incompatible pointer type
:info:build unexmacosx.c:1402: warning: cast to pointer from integer of
different size
:info:build unexmacosx.c: In function ?get_dsize?:
:info:build unexmacosx.c:1413: warning: initialization from incompatible
pointer type
:info:build gcc  -c -pipe -O2 -arch x86_64 -Wall -DVOL=volatile
-fsigned-char -pipe -O3 -fomit-frame-pointer
-
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcl/gcl/work/gcl-2.6.7/o
-I../h -I../gcl-tk funlink.c
:info:build In file included from funlink.c:978:
:info:build xdrfuns.c: In function ?siGxdr_write?:
:info:build xdrfuns.c:50: warning: passing argument 2 of ?xdr_long? from
incompatible pointer type
:info:build xdrfuns.c: In function ?siGxdr_read?:
:info:build xdrfuns.c:109: warning: passing argument 2 of ?xdr_long?
from incompatible pointer type
:info:build gcc  -c -pipe -O2 -arch x86_64 -Wall -DVOL=volatile
-fsigned-char -pipe -O3 -fomit-frame-pointer
-
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcl/gcl/work/gcl-2.6.7/o
-I../h -I../gcl-tk plt.c
:info:build In file included from plt.c:41:

Re: gcl fail

On 01/02/2012 03:47, Phil Dobbin wrote:
> Hi, all.
> 
> I'm trying to install gcl on 10.6.8 & the tail of main.log is:

[snip]

FWIW, I tried compiling this from a tarball on OS X & Linux & got a
permission denied when trying create `bin/gcl`.

HTH,

Cheers,

  Phil...

Noobish question

Re: Noobish question

On Feb 1, 2012, at 4:42 AM, Aljaž Srebrnič wrote:

> Hello!
> Sorry to bother you, but I need to eliminate the CPATH variable in the build phase, that is currently
CPATH="/opt/local/include", I tried adding first build.env-delete CPATH="/opt/local/include",
and then I tried build.env-append CPATH="". None of this is working… Where am I wrong?

The guide says build.env has no default:
http://guide.macports.org/#reference.phases.build

Are you using a PortGroup?

Maybe compiler.cpath?
pillbox:trunk brad$ grep -R CPATH base
base/src/port1.0/portutil.tcl:        set ${command}.env_array(CPATH) [join [option compiler.cpath] :]

Regards,
Bradley Giesbrecht (pixilla)

_______________________________________________
macports-users mailing list
macports-users <at> lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: Noobish question

No, no PortGroup is used, but compiler.cpath solves the issue!
It is strangely undocumented, though… :/

Aljaž Srebrnič
-- --
My public key:  http://bit.ly/g5pw_pubkey

On 01/feb/2012, at 17:55, Bradley Giesbrecht wrote:

> On Feb 1, 2012, at 4:42 AM, Aljaž Srebrnič wrote:
> 
>> Hello!
>> Sorry to bother you, but I need to eliminate the CPATH variable in the build phase, that is currently
CPATH="/opt/local/include", I tried adding first build.env-delete CPATH="/opt/local/include",
and then I tried build.env-append CPATH="". None of this is working… Where am I wrong?
> 
> The guide says build.env has no default:
> http://guide.macports.org/#reference.phases.build
> 
> Are you using a PortGroup?
> 
> Maybe compiler.cpath?
> pillbox:trunk brad$ grep -R CPATH base
> base/src/port1.0/portutil.tcl:        set ${command}.env_array(CPATH) [join [option compiler.cpath] :]
> 
> 
> 
> Regards,
> Bradley Giesbrecht (pixilla)
> 
> 
> 
> 
> 

Re: Noobish question

On Feb 1, 2012, at 10:58, Aljaž Srebrnič wrote:

> No, no PortGroup is used, but compiler.cpath solves the issue!
> It is strangely undocumented, though… :/

Yup. It was never clear to me why we added CPATH and LIBRARY_PATH to MacPorts base, since the existing
CPPFLAGS and LDFLAGS we set in the configure phase should have the same effect for properly-behaved
ports, and improperly-behaved ports should be fixed. Now that Xcode 4.2 users are using clang, and clang
does not use CPATH or LIBRARY_PATH [1], it may truly be time to admit that CPATH and LIBRARY_PATH are not
helping us (they are merely causing those of us who don't use clang to commit ports that may not work for
users using clang), and remove them.

Then again, this may be fixed in future versions of clang. CPATH support was already added [2]; adding
LIBRARY_PATH support [3] has not been discussed yet however.

Out of curiosity, why are you needing to remove CPATH? What problem is having it set causing you?

[1] http://lists.macosforge.org/pipermail/macports-dev/2011-August/015543.html
[2] http://llvm.org/bugs/show_bug.cgi?id=8971
[3] http://llvm.org/bugs/show_bug.cgi?id=10296

_______________________________________________
macports-users mailing list
macports-users <at> lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users