[Dspace-tech] Backup Failure
Nigel Pegus
Hello all,
I am running dspace 1.4.1 on linux enterprise Version 3 update 6 have just tried copying the data folder and assetstore folder form my test server to the production server to test a Backup procedure. I am now unable to start the postgres database. I Backed up the original production data and assetstore folders then deleted them and copied over the test server ones, I noted that I had to re assign the assetstore to the dspace user as the root user for some reason came up as the owner after the copy. I Also had to make the postgres user the owner of the data folder again. Now when I return to the original data and assetstore folders I get the same error…
I get this error when trying to start postgres database:
pg_ctl: another server may be running; trying to start server anyway
pg_ctl: could not start server
Examine the log output.
Also I am unable to locate the postgres log file, this is my postgres start up command /usr/local/pgsql/bin/pg_ctl -D /dbdata/data -l logfile start Can anyone point me in the direction of the postgres logfile?
The dspace log file reflects what looks like two general errors (Ive pasted them below) when trying to run cronjobs for checksum / filter media / DailyReportEmailer I’m not sure what cronjob is generating the errors, but of course these errors are in response to my moving the data and assetstore folders coupled with root taking ownership of the folders. I am now unclear as to why I cannot restart postgres even after restoring the original folders and ensuring the original owners are assigned. Does anyone have any input on this issue??
Thanks,
Nigel
2008-02-12 20:00:08,121 WARN org.dspace.jsp @ anonymous:session_id=F3F09DDEDAC04171EF9B9991C178C8EA:ip_addr=192.168.254.3:database_error:org.postgresql.util.PSQLException: ERROR: could not open relation 1663/16386/1259: Permission denied
org.postgresql.util.PSQLException: ERROR: could not open relation 1663/16386/1259: Permission denied
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:236)
at org.postgresql.jdbc2.AbstractJdbc2DatabaseMetaData.getPrimaryKeys(AbstractJdbc2DatabaseMetaData.java:2941)
at org.dspace.storage.rdbms.DatabaseManager.retrieveColumnInfo(DatabaseManager.java:1530)
at org.dspace.storage.rdbms.DatabaseManager.getColumnInfoInternal(DatabaseManager.java:1498)
at org.dspace.storage.rdbms.DatabaseManager.getColumnInfo(DatabaseManager.java:890)
at org.dspace.storage.rdbms.DatabaseManager.getColumnNames(DatabaseManager.java:963)
at org.dspace.storage.rdbms.DatabaseManager.process(DatabaseManager.java:1223)
at org.dspace.storage.rdbms.TableRowIterator.next(TableRowIterator.java:151)
at org.dspace.content.Community.findAllTop(Community.java:275)
at org.apache.jsp.index_jsp._jspService(index_jsp.java:92)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:384)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:595)
Nigel Pegus
Main Library, Systems Unit
The University of the West Indies
ext: 2241
Nigel Pegus
Hello again Jeff
I have been experimenting with the grep command on my test server and production server. The command to start the database seams to execute but when I check for a process ID I do not get one for postmaster and I verified there is no postmaster.pid file in data this time. Is there another step I am missing to restart the database??
Thanks again,
Nigel
From: Jeffrey Trimble
[mailto:jtri...@cc.ysu.edu]
Sent: Wednesday, February 13, 2008
2:33 PM
To: Nigel
Pegus
Subject: Re: [Dspace-tech] Backup
Failure
Nigel,
You have a "postmaster.pid" file that needs to be deleted. Delete it and start your postgres.
Things should return to normal
--jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
DSpace-tech mailing list
Nigel Pegus
To All,
Turns out I had what seams to have been two major problems,
1) as Jeffrey pointed out I had a postmaster.pid file still present in
the data folder which needed to be deleted so postgres could restart
2) I had to reset permissions on the folders to the correct owners
(dspace for assetstore and postgres for data)but I didnt notice that
when I reset permissions on data folder, ownership was also granted to
the group and world as well which prevented postgres from starting
also..
Hopefully this post will assist anyone who runs into a similar issue...
Thanks again,
Nigel
-----Original Message-----
From: Robin Taylor [mailto:robin....@ed.ac.uk]
Sent: Thursday, February 14, 2008 5:31 AM
To: Nigel Pegus
Subject: RE: [Dspace-tech] Backup Failure
Hi Nigel,
Every Unix user has a uid, a number, as well as a name. When you copy
files
from one machine to another (with tar ?) it will try and assign the
files to
the user with the same uid on the new machine, the dspace user on the
new
machine may well have a different uid. My guess is that it couldn't find
a
user with the same uid so assigned the files to root.
I am a wee bit surprised that you tried to copy over the postgres data
folder. I think it would be better to run a backup and restore using
postgres commands (pg_dump).
Postgres logs go to std_out (or std_err ?) by default. You need to make
a
change to the postgres conf file if you want it to go somewhere
permanent.
Hope some of this helps.
Cheers, Robin.
-----Original Message-----
From: dspace-te...@lists.sourceforge.net
[mailto:dspace-te...@lists.sourceforge.net] On Behalf Of Nigel
Pegus
Sent: 13 February 2008 18:21
To: DSpac...@lists.sourceforge.net
Subject: [Dspace-tech] Backup Failure
Hello all,
I am running dspace 1.4.1 on linux enterprise Version 3 update 6 have
just
tried copying the data folder and assetstore folder form my test server
to
the production server to test a Backup procedure. I am now unable to
start
the postgres database. I Backed up the original production data and
assetstore folders then deleted them and copied over the test server
ones, I
noted that I had to re assign the assetstore to the dspace user as the
root
user for some reason came up as the owner after the copy. I Also had to
make
the postgres user the owner of the data folder again. Now when I return
to