Errors Restoring XI

[Fred Kroeger]

Excellent questions because it got me looking closer at the creation process instead of the import side.
Yes there is enough space on the source system, but checking it I found that I wasn't using the current version of the backup script.
I had copied the original sometime ago and modified it because it didn't work correctly when you use the "-n" option.
So I have updated my cron now to backup using the current script & we'll see what happens tonight (assuming the -n issues have been fixed!).

Code: Select all

/usr/local/nagiosxi/scripts/backup_xi.sh -n `/bin/hostname -s`

[tgriep]

Report back what you find out about this.

[Fred Kroeger]

All good.... except for a small problem on line 217 of restore_xi.sh

Code: Select all

Restoring MySQL databases...
./restore_xi.sh: line 217: service: command not found
Restoring Nagios XI PostgresQL database...

As I run this script via cron, the path is not set, so it appears that the service command is failing

Code: Select all

Line 217 =  service postgresql start

I've noticed that in the rest of the restore script another script is used to mange the services - $BASEDIR/manage_services.sh
Did this line get overlooked ?

regards... Fred

[Box293]

It's currently Thanksgiving holidays in the USA and the support office is closed. I would not expect a reply until next week.

[Fred Kroeger]

Thanks Troy - it can wait until then.

Regards.... Fred

[hsmith]

You need to run the script from inside of the /usr/local/nagiosxi/scripts directory. You can't call it's path, you need to actually cd to the directory.

[lmiltchev]

In addition to this, can you run the following commands on the "new" server and show the output?

Code: Select all

which service
echo $PATH
which postgres
service postgresql start
service postgresql status

Note: If the db is not initialized, you may need to run:

Code: Select all

service postgresql initdb
service postgresql start

[Fred Kroeger]

Yes the command is being run from /usr/local/nagiosxi/scripts directory
The "new" server is actually a DR server which I refresh with the backup from the Prod server. So it is a working server.

The restore is run via cron and all of Nagios works fine after the restore.

Not sure what the info you need will help with - but here it is

Code: Select all

# which service
/sbin/service

# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin

# which postgres
/usr/bin/postgres

My original question is why line 217 has "service postgres start" when all the service requests in the script call $BASEDIR/manage_services.sh ?
Surely that is the problem?

Fred

[lmiltchev]

Not sure what the info you need will help with - but here it is

I wanted to make sure you don't have any issues with service/path and wanted to see the output of:

Code: Select all

service postgresql start
service postgresql status

Can you run the commands listed above successfully on this machine?

In the "restore_xi.sh" (line 217), you could try changing this:

Code: Select all

service postgresql start

to this:

Code: Select all

$BASEDIR/manage_services.sh start postgresql

I am not sure if this is going to fix the issue... "service postgresql start" should have worked.
What is the OS/distro/architecture of this box?

Code: Select all

uname -a
cat /etc/*release

[Fred Kroeger]

Thanks Ludmil
All these commands work fine from the command line - the restore script also works fine from the command line.
I have been stressing that this restore is run via cron and it is then that the error message is displayed. The users PATH is not inherited when you run the script via cron - so having the command "service" without it's full path will never work if you don't set the PATH variable at the start of the script.
Also it is the only "service" command in the script - all the other "service" tasks in the restore script are handled by the $BASEDIR/manage_services.sh script.
And yes I can change line 217 to use the manage_services.sh script and I'm absolutely sure that this will work OK. But it makes more sense that you make this change so that it works for everybody.
As I mentioned previously, it is the only line left in the restore script that calls the service command directly - every other service command is run via mange_services.sh - so to me it looks like an ovesight.

regards... Fred