------=_Part_12712_21867749.1208748916470
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
The usual trap in cron usage is the fact that crontab commands are
executed
in a cleanroom environment, ie no environment variable is used/inherited,
so
PATH, HOME, PGDATA, etc are not set/available when the command is
launched.
You can set vars or be very explicit in your script including DB names, DB
Users, etc
Cheers
Medi
On Sun, Apr 20, 2008 at 5:08 PM, Phillip Smith <
phillip.smith@[EMAIL PROTECTED]
> wrote:
> > same result when it running trough cronjob. Manually everything is
> > fine. Even I put this commands (without su -l ...) in postgres user
> > crontab, but same result.
> >
> > Server is ubuntu 64bit. Does it makes any difference from 32bit in
> > terms of crontab functionality?
>
> System architecture shouldn't affect crontab. Can you give us the
> full output from cron? Also, just for debugging's sake, try putting
> it in a script and call the script from cron.
>
> If it still fails, then it might help identify exactly where the
> error is. If it doesn't fail, then you can start shrinking it all
> back down in to one line again and see where the error comes in.
>
> #!/bin/bash
>
> BACKUP_FILE_GZ='/backup/rms.gz'
> BACKUP_FILE='/tmp/rms.sql'
>
> echo "-----------------------------------------------"
> echo "Unzipping backup..."
> /bin/gunzip -c ${BACKUP_FILE_GZ} > ${BACKUP_FILE}
>
> echo "-----------------------------------------------"
> echo "Attempting restore..."
> /usr/bin/psql rms < ${BACKUP_FILE}
>
> echo "-----------------------------------------------"
> echo "Done"
>
>
> THINK BEFORE YOU PRINT - Save paper if you don't really need to print
this
>
> *******************Confidentiality and Privilege
Notice*******************
>
> The material contained in this message is privileged and confidential to
> the addressee. If you are not the addressee indicated in this message
or
> responsible for delivery of the message to such person, you may not copy
> or deliver this message to anyone, and you should destroy it and kindly
> notify the sender by reply email.
>
> Information in this message that does not relate to the official
business
> of Weatherbeeta must be treated as neither given nor endorsed by
> Weatherbeeta.
> Weatherbeeta, its employees, contractors or associates shall not be
liable
> for direct, indirect or consequential loss arising from transmission of
> this
> message or any attachments
> e-mail.
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@[EMAIL PROTECTED]
)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>
------=_Part_12712_21867749.1208748916470
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
The usual trap in cron usage is the fact that crontab commands are
executed in a cleanroom environment, ie no environment variable is
used/inherited, so PATH, HOME, PGDATA, etc are not set/available when the
command is launched. <br>
<br>You can set vars or be very explicit in your script including DB
names, DB Users, etc<br><br>Cheers<br>Medi<br><br><div
class="gmail_quote">On Sun, Apr 20, 2008 at 5:08 PM, Phillip Smith <<a
href="mailto:phillip.smith@[EMAIL PROTECTED]
">phillip.smith@[EMAIL PROTECTED]
>>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204,
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> same result
when it running trough cronjob. Manually everything is<br>
> fine. Even I put this commands (without su -l ...) in postgres
user<br>
> crontab, but same result.<br>
><br>
> Server is ubuntu 64bit. Does it makes any difference from 32bit
in<br>
> terms of crontab functionality?<br>
<br>
System architecture shouldn't affect crontab. Can you give us the<br>
full output from cron? Also, just for debugging's sake, try
putting<br>
it in a script and call the script from cron.<br>
<br>
If it still fails, then it might help identify exactly where the<br>
error is. If it doesn't fail, then you can start shrinking it all<br>
back down in to one line again and see where the error comes in.<br>
<br>
#!/bin/bash<br>
<br>
BACKUP_FILE_GZ='/backup/rms.gz'<br>
BACKUP_FILE='/tmp/rms.sql'<br>
<br>
echo "-----------------------------------------------"<br>
echo "Unzipping backup..."<br>
/bin/gunzip -c ${BACKUP_FILE_GZ} > ${BACKUP_FILE}<br>
<br>
echo "-----------------------------------------------"<br>
echo "Attempting restore..."<br>
/usr/bin/psql rms < ${BACKUP_FILE}<br>
<br>
echo "-----------------------------------------------"<br>
echo "Done"<br>
<br>
<br>
THINK BEFORE YOU PRINT - Save paper if you don't really need to print
this<br>
<br>
*******************Confidentiality and Privilege
Notice*******************<br>
<br>
The material contained in this message is privileged and confidential
to<br>
the addressee. If you are not the addressee indicated in this
message or<br>
responsible for delivery of the message to such person, you may not
copy<br>
or deliver this message to anyone, and you should destroy it and
kindly<br>
notify the sender by reply email.<br>
<br>
Information in this message that does not relate to the official
business<br>
of Weatherbeeta must be treated as neither given nor endorsed by
Weatherbeeta.<br>
Weatherbeeta, its employees, contractors or associates shall not be
liable<br>
for direct, indirect or consequential loss arising from transmission of
this<br>
message or any attachments<br>
e-mail.<br>
<font color="#888888"><br>
--<br>
Sent via pgsql-admin mailing list (<a
href="mailto:pgsql-admin@[EMAIL PROTECTED]
">pgsql-admin@[EMAIL PROTECTED]
>)<br>
To make changes to your subscription:<br>
<a href="http://www.postgresql.org/mailpref/pgsql-admin"
target="_blank">http://www.postgresql.org/mailpref/pgsql-admin</a><br>
</font></blockquote></div><br>
------=_Part_12712_21867749.1208748916470--
|
