gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Postgres 8.4.4-1 (Enterprise db) problems -- system h


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Postgres 8.4.4-1 (Enterprise db) problems -- system hosed?
Date: Mon, 5 Jul 2010 10:36:34 +0200
User-agent: KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.3; i686; ; )

Am Montag 05 Juli 2010, 09:58:10 schrieb Karsten Hilbert:
> On Mon, Jul 05, 2010 at 08:36:38AM +0200, Hilbert, Sebastian wrote:
> > > The above problem was (I think) distinct from the problem with UTF8 and
> > > clusters. Does the exception above likely arise from some issue of file
> > > permissions (ownership) when a user would have downloaded the server
> > > files into personal user space, and then tried to run the installer as
> > > root-becoming(su to)-postgres ?
> > 
> > Yes it is seperate and yes it is a permission problem. Since it works in
> > /tmp I can only assume that it wants to write something which is not
> > allowed.
> 
> It does not. It tries to read the Current Working Directory.
> For which call it does not have permissions (it does have
> permissions to the directory itself, just not for the call,
> which may arise from lacking permissions *along the path* of
> the cwd). I consider it a plain bug in Python on Mac to not
> be able to determine the cwd if I have permissions to read
> that directory.
> 
> > It starts between v6 and v7
> 
> Because that is the first time we need to determine the cwd.
> 
> > and my guess is when it tries to go to v7 it wants
> > to access more then the conf files (e.g. data files)
> 
> Exactly, that's why.
> 
> > This is the relevant part from the log:
> > 
> > File "./bootstrap_gm_db_system.py", line 934, in import_data
> > 
> >     script_base_dir =
> >     os.path.abspath(os.path.expanduser(script_base_dir))
> >   
> >   File
> > 
> > "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.
> > 6/posixpath.py", line 341, in abspath
> > 
> >     cwd = os.getcwdu()
> > 
> > OSError: [Errno 13] Permission denied
> 
> Well, check the value of script_base_dir (should be
> something like ../server/sql/v6-v7/python/) and look up the
> permissions in the file system.

The base directory has the permissons of the logged in user (when unzipped as 
this user) and the subsequent directories have the permissions of the original 
user in the tarball ( might be unknown user)

As stated before it works if you untar into /tmp

That would make me think that it has nothing to do with the subdirectories of 
the tarball but rather getcwd or getcwdu does not work in the user's 
directory. It would be interesting to see which user issues the getcwd call 
(root ? postgres ? loged-in user ?)

Sebastian

Sebastian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]