Hi,
First make sure the alarmprogram is executable by informix and really gets called.
For debugging the alarm events, put a line somewhere near the beginning like:
echo "`date +%Y%m%d%H%M%S` $1,$2,$3,$4,$5" >> /tmp/alarm_${INFORMIXSERVER}.out
You should see each event triggered in the log (informix user should be able to write to the file ...)
After the case "$EVENT_SEVERITY" block, put another
echo ${BACKUPLOGS} ${LTAPEDEV} ${BACKUP_CMD} >> /tmp/alarm_${INFORMIXSERVER}.out
You should get a 23 event (LOGICAL LOG FILE COMPLETED) for each log filling up.
Add more output there for investigation, echo the full command call to the alarm_${INFORMIXSERVER}.out file.
Redirect the error output of the BACKUP_CMD call to the same output to see what really happens.
Are you using onbar or ontape ?
This event can be manually enforced in a testing environment with onmode -l (force next log).
We have been using almost the same script for this purpose since version 11.x I think.
So any script from 12.x should at least do something with the common events (which did not change).
Hope this helps.
Original Message:
Sent: 2/8/2024 4:05:00 PM
From: John David Adamski
Subject: RE: Logical logs backups acting weird after upgrade from 12.10.FC13 to 14.10.FC10
Sorry my post formatting was a bit off, since last Outlook update been having problems with what I type and what is sent being totally different format wise.
The current alarmprogram.sh I have in place is the v12 version, and was working prior to the upgrade with no problems. So no new stuff from v14. Still not working. I originally tried the v14 one with the BACKUPLOGS and BACLUP_CMD changed to what I need.
When it does work, I see a corresponding log in /backups and onstat -l shows the B to that log. When it not working I see one or more logs with U but no B, as expected.
Even stranger I am not getting two emails each 15 odd minutes with the % full message. Had to deal with a "the sky is falling" situation and didn't have any time today to look at. Will add debug line in script to see if that points to something.
Hopefully I will have a quieter Friday to do some debugging.
Thanks for the suggestions.
john
Original Message:
Sent: 2/8/2024 11:08:00 AM
From: Andreas Legner
Subject: RE: Logical logs backups acting weird after upgrade from 12.10.FC13 to 14.10.FC10
The BACKUP_CMD you're citing doesn't look to be the default one, so which alarmprogram.sh is this in - v12's or v14's?
In other words: is this really the command being executed? Do you see log backups getting created in /backups?
And regarding your logical logs, when getting those emails: does "onstat -l" show multiple logs carry U (used) but no B (backed up) flag? I.e. are logs not getting backed up when they should.
The ALARMPROGRAM should be called with each logical log filling or, more precisely, with each switch to a new logical log.
I'd start by tracing this script, e.g. by putting some "echo $(date) 'did this and that, on line x' >> /tmp/alarmprog.trace".
HTH,
Andreas
------------------------------
Andreas Legner
------------------------------
Original Message:
Sent: Thu February 08, 2024 10:48 AM
From: John David Adamski
Subject: Logical logs backups acting weird after upgrade from 12.10.FC13 to 14.10.FC10
IDS 12.10.FC13 to 14.10.FC10
NAME="SLES" VERSION="15-SP5"
Our ERP finally released IDS14 for us to upgrade to. I ran the upgrade on our test/dev vm and the upgrade went well. However the logical log backups are just acting weird. We use the alarmprogram (BACKUP_CMD="ontape -a -d") to "/backups" directory. Sometimes it seems to do the backup and other times it seems to just be waiting. Granted not a lot of activity is happened currently on the test/dev so don't expect lots of logs.
I'm getting emails from IDS with subject of Logs at 81.5% full or whatever the % is and body of
Hello,
The logical logs on the onconf.cars OnLine Engine are
at 81.5% full. Please take appropriate steps.
Thank You
I'm assuming IDS is generating these as not sure what else would.
We have a mixture of buffered and unbuffered databases.
adamski cars: echo "select name[1,20], is_logging, is_buff_log from sysdatabases" | dbaccess sysmaster
Database selected.
name is_logging is_buff_log
sysmaster 1 0
sysutils 1 0
sysuser 1 0
sysadmin 1 0
uni93 1 0
cars_audit 1 0
cars 1 0
uni97 1 1
train 1 1
uni103 1 1
10 row(s) retrieved.
Snip-it from onconf
ALARMPROGRAM $INFORMIXDIR/etc/alarmprogram.sh
ALRM_ALL_EVENTS 0
STORAGE_FULL_ALARM 600,3
SYSALARMPROGRAM $INFORMIXDIR/etc/evidence.sh
LTAPEDEV /backups
LTAPEBLK 512
LTAPESIZE 0
Snip-it of alarmprogram.sh -- make sure top line is #!/bin/ksh
BACKUPLOGS=Y
ALARMADMIN=0
ALARMPAGER=0
ADMINEMAIL=
PAGEREMAIL=
BACKUP_CMD="ontape -a -d"
RM="rm -f"
ONSTATCMD="onstat"
adamski cars: ll onconf.cars
-rw-r--r-- 1 informix informix 90619 Feb 7 12:37 onconf.cars
adamski cars: ll alarmprogram.sh
-rwxr-xr-x 1 informix informix 20022 Feb 7 13:01 alarmprogram.sh
I have made a full instance backup, bounced IDS and even rebooted server and still sometimes I get the logs to backup other times just the emails saying logs getting full.
Anyone have a suggested starting point to troubleshoot as I been through all my notes from prior upgrades and nothing I did in the past to get logs backing up have seemed to help this time.
John David Adamski
Sr. Sysadmin/DBA
Graceland University
1 University Place, Lamoni, IA 50140
adamski@graceland.edu
641-784-5267