alarmprogram.sh not backing up logs after upgrade

This seems to happened every time I upgrade our ERP server. SUSE Enterprise (SLES) 11.4 -> 15.4 and Informix 12.10.FC7 to 12.10.FC13 Added some debug lines in the script and showing a 127 error - which not sure makes sense as permissions look ok I think. can't seem to figure out what the problem is. Any ideas? below the out put of the debug lines: DATE_INT=2022270090543 DBCENTURY=C HOME=/home/carsids/informix INFORMIXDIR=/opt/informix INFORMIXSERVER=novaINVOCATION_ID=43cbbf3f30344e81a6352a33a799ec2f JOURNAL_STREAM=8:22579 LANG=C LOGNAME=informix ONCONFIG=onconf.cars PATH=/sbin:/usr/sbin:/bin:/usr/bin:$INFORMIXDIR/binPWD=/ SHELL=/usr/bin/csh SHLVL=1 SYSTEMD_EXEC_PID=1735 USER=informix XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/ _=/usr/bin/env BACKUPLOGS before if = Y BACKUP_CMD = ontape -a -d BACKUPLOGS EXIT_STATUS = 127 what manual says 127 means 127 Could not write to the emergency boot file. Often, an operating-system error message accompanies this problem. Check the permissions on the following files and directories: $INFORMIXDIR/etc on UNIX(tm) or %INFORMIXDIR%\\etc on Windows(tm) The emergency boot file echo $INFORMIXDIR /opt/informix informix cars: ll / | grep opt drwxr-xr-x 20 root root 4096 Mar 15 2022 opt informix cars: ll /opt | grep informix drwxr-xr-x 35 informix informix 4096 Sep 26 23:57 informix informix cars: ll /opt/informix | grep etc drwxrwxr-x 10 informix informix 4096 Sep 27 09:02 etc which ksh /bin/ksh what I added to alarmprogram.sh # -- GU ( env | sort ptree $$ ) > /tmp/jda.txt echo "BACKUPLOGS before if = $BACKUPLOGS" >> /tmp/jda.txt # -- GU if [ "x${BACKUPLOGS}" = xY ] then # -- GU # $BACKUP_CMD 2>&1 >> /dev/null echo "BACKUP_CMD = $BACKUP_CMD" >> /tmp/jda.txt $BACKUP_CMD 2>&1 >> /tmp/jda.txt # -- GU EXIT_STATUS=$? printf " '$BACKUP_CMD' has been executed and returned CODE=%s\\n\\n" $EXIT_STATUS # -- GU echo "BACKUPLOGS EXIT_STATUS = $EXIT_STATUS" >> /tmp/jda.txt # -- GU John David Adamski Sr. Sysadmin/DBA Graceland University 1 University Place, Lamoni, IA 50140 adamski@graceland.edu 641-784-5267 #Informix

The 127 error here is an OS error for "command not found", and not an Informix error. It seems that the ontape command itself is not found. You can always add "which ontape" as one of your debugging messages if you want to confirm this. Your PATH looks weird as normally you would expect the "$INFORMIXDIR" to be expanded to the actual directory of "/opt/informix" rather than still showing $INFORMIXDIR. While INFORMIXDIR may be correct in your environment, I suspect that the PATH was not set correctly or exported correctly when informix was started up. That's just a guess though. ------------------------------ Mike Walker xDB Systems, Inc www.xdbsystems.com ------------------------------

John, I happened to notice this in your debugging: SHELL=/usr/bin/csh But later you reference ksh. Not sure if this could be the issue but thought I would mention it. David Link

Mike Oooooooooooooooooh so an OS error. Ok will look into that and yes I thought the PATH was weird looking. But wasn't sure. Thanks for the lead. john

I did a which on ksh as read some Informix commands run on it and not the default shell. Was just showing we have ksh installed. Should have explained better. john

change alarmprogram.sh to realalarmprogam.sh?? and create a new alarmprogram.sh does something like ... #! /bin/bash ( env set -x realalarmprogram.sh $* ) > /tmp/alarmprogram.wtf 2>&1 -- Cheers Paul Paul Watson Oninit LLC +1-913-387-7529 Oninit is a Registered Trademark of Oninit LLC

That seems to be the problem. To verify I modified the script to fully qualify the path for ontape and it works. Now got to figure out why its not getting the correct PATH. The user Informix looks fine. informix cars: echo $PATH .:.:/home/carsids/informix:/opt/carsi/modules/graceland/scripts/:/opt/carsi/install/cis:/opt/perl530/bin:/opt/gnu/bin:/usr/java/java8/bin:/bin:/usr/bin:/usr/local/bin:/opt/carsi/install/utl:/opt/carsi/install/bin:/opt/informix/bin:/opt/gnu/bin:/usr/X11R6/bin:/opt/openldap/bin:/usr/local/bin:/usr/contrib/bin:/usr/bin/X11:/usr/contrib/bin/X11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bin:/opt/ytalk/bin/X11:/opt/carstrain/install/scp/graceland/:/opt/carsi/modules/graceland/scripts/ The ERP give us the Informix installer script they create so do the upgrade so must be a problem in that. john

The actual problem was when the ERP vendor was coding the switch from inetd to systemctl they had an extra '$' in the conf file for informix for systemctl to use. Removing the '$' and bouncing informix fixed the problem. john