Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Reinhard Habichtsberg found logical log backup via ALARMPROGRAM failed (exit code 127) when Informix 12.10.FC10 on CentOS 7 was started by systemd, but worked via oninit. Luis Marques suspected ontape was missing from PATH. Reinhard confirmed systemd did not expand $PATH in its config file; setting the full PATH fixed it. Solved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hi All,
we configured systemd on CentOs7 to start and stop informix server 12.10.FC10.
Im not sure of the type of the service so I tried oneshot, simple and forking.
Informix starts in all cases. I see no difference.
But we have an issue: If starting informix via systemd, the automatic backup
of the logical logs will not work.
In onconfig we have set:
ALARMPROGRAM $INFORMIXDIR/etc/log_full_ontape.sh
cat $INFORMIXDIR/etc/log_full_ontape.sh
#!/bin/sh
###########################################################################
#
# Licensed Material - Property Of IBM
#
# "Restricted Materials of IBM"
#
# IBM Informix Dynamic Server
# (c) Copyright IBM Corporation 1996, 2004 All rights reserved.
#
# Title: log_full.sh
#
# Description Automates logical log backup using event alarms from the
# database server. To install this script, add the following
# line to the ONCONFIG file -
# ALARMPROGRAM <informixdir>/etc/log_full.sh
# where <informixdir> is replaced by the full value of
# $INFORMIXDIR
#
##############################################################################/
PROG=`basename $0`
USER_LIST=informix
#BACKUP_CMD="onbar -b -l"
BACKUP_CMD="ontape -a -d"
EXIT_STATUS=0
EVENT_SEVERITY=$1
EVENT_CLASS=$2
EVENT_MSG="$3"
EVENT_ADD_TEXT="$4"
EVENT_FILE="$5"
case "$EVENT_CLASS" in
23)
# onbar assumes no operator is present,
# so all messages are written to the activity
# log and there shouldn't be any output, but
# send everything to /dev/null just in case
$BACKUP_CMD 2>&1 >> /dev/null
EXIT_STATUS=$?
;;
# One program is shared by all event alarms. If this ever gets expanded to
# handle more than just archive events, uncomment the following:
*)
# EXIT_STATUS=1
;;
esac
exit $EXIT_STATUS
Thats nothing extra. And it works fine, if we start the informix server "by
hand" with oninit.
Only when started by systemd automatic backup of logical logs don't work.
Has anyone experienced this and could help?
TIA,
Reinhard.
I found these messages in the online.log:
12:03:03 Logical Log 405 Complete, timestamp: 0x5e33b69.
12:03:03 Process exited with return code 127: /bin/sh /bin/sh -c
/opt/informix/etc/log_full_ontape.sh 2 23 "Logical Log 405 Complete,
timestamp: 0x5e33b69." "Logical Log 405 Complete, timestamp: 0x5e33b69." ""
23001
I found that not the script /opt/informix/etc/log_full_ontape.sh is critical
but the sequence:
/bin/sh /bin/sh -c. If I try this the error messages is:
/bin/sh: /bin/sh -c: cannot execute binary file
Is it in some way possible to avoid that systemd puts the /bin/sh before the
rest of the statement when starting sub-programs?
TIA, Reinhard.
↪ replying to REINHARD HABICHTSBERG
LUIS MARQUES — — source: IIUG Forums & Mailing Lists
When starting Infomix via systemd, what is the value of PATH on the output of
"onstat -g env" ?
Probably only the usual "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
which means that "ontape" is not in the executable path and you are getting
the "-127" exit code.
Either add "$INFORMIXDIR/bin" to the PATH inside the script or use the
absolute path for the "ontape" command.
Hi Luis,
solved! Thank you!
The reason ist that systemd does not expand the environment variables which
are provided in the config file /etc/systemd/informix.conf:
onstat -g env:
PATH $PATH:$INFORMIXDIR/bin
I modified the file and we see:
PATH /opt/informix/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:...
And the automatic backup of the logical logs work fine.
Thanks again,
Reinhard
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.