Informix Error -25

Operating-System Meaning

errno 25 is ENOTTY. The official "Not a typewriter" is the oldest wording anywhere in this range — a direct survival from Unix Version 7, when a TTY was a teletypewriter. Every current system renders it "Inappropriate ioctl for device", which describes what actually happened.

The modern name is the accurate one, and the historic one actively misleads: this error is usually nothing to do with terminals.

ENOTTY means an ioctl() was issued that the target device does not support. Terminals are simply where the error originated historically — asking a non-terminal for terminal attributes — but the same refusal applies to any device asked to do something outside its repertoire.

Its neighbours in this range cover the other ways a device path can be wrong:

errno	Meaning
15 ENOTBLK	The wrong kind of object — a block device was required
19 ENODEV	No driver claims it, or the device cannot do this at all
25 ENOTTY	The device exists and works; this specific ioctl is not one it supports

What This Means in Informix

Tape parameters pointing at something that is not a tape

The official text names this: "an incorrect address in the log-device parameter" — LTAPEDEV, and equally TAPEDEV.

Backup code issues tape control operations — rewind, position, retension, status — as ioctl calls. Point the parameter at a regular file, a disk device or a directory and those calls are rejected with ENOTTY. The path opens perfectly well, which is what makes it confusing: reads and writes succeed, and only the control operations fail.

This is the same underlying mistake as -15 and -19, arriving through a different door. If you are chasing any of the three against a tape parameter, check all of them.

Backing up to disk is entirely legitimate — but it has to be configured as such rather than by aiming a tape parameter at a file and hoping the semantics follow.

Running without a terminal

The second family is genuinely common and has nothing to do with tape: a program asking for terminal attributes when its input or output is not a terminal.

This surfaces when an interactive-minded utility runs under cron, under a scheduler, through a pipe, or from a CI job — anywhere stdin/stdout is a pipe or a file rather than a TTY. Well-behaved programs test with isatty() first and adapt; less careful ones issue the ioctl regardless and report the failure.

The characteristic presentation: works when run by hand, fails from cron, with nothing else different.

Elsewhere

• A wrapper or monitoring script querying terminal size or attributes in a non-interactive context
• A storage-manager integration issuing device controls against the wrong node
• A utility invoked with its output redirected where it expects a terminal

Common Causes

1. TAPEDEV or LTAPEDEV naming a regular file, disk or directory rather than a tape device.
2. A program run without a terminal — cron, a scheduler, a pipe, a container without a TTY.
3. An ioctl inappropriate for the device type, from a wrapper or integration.
4. A backup-to-disk arrangement improvised by repointing tape parameters.

Diagnostic Checks

Check the tape parameters and what they actually point at:

grep -nE 'TAPEDEV|LTAPEDEV|TAPEBLK|LTAPEBLK|TAPESIZE' "$INFORMIXDIR/etc/$ONCONFIG"

for p in $(awk '/^(TAPEDEV|LTAPEDEV)/ {print $2}' "$INFORMIXDIR/etc/$ONCONFIG"); do
    printf '%-40s %s\n' "$p" "$(stat -c '%F' "$p" 2>/dev/null || echo MISSING)"
done

character special file is what a tape device should report. regular file, directory or block special file is the fault.

Confirm from the other direction — a tape command against the path:

mt -f /dev/st0 status
mt -f "$(awk '/^LTAPEDEV/ {print $2}' "$INFORMIXDIR/etc/$ONCONFIG")" status

Inappropriate ioctl for device from mt is the same finding, reproduced outside Informix in one command.

For the terminal case, establish whether there is one:

tty                                    # "not a tty" when there is none
test -t 0 && echo "stdin is a tty"   || echo "stdin is NOT a tty"
test -t 1 && echo "stdout is a tty"  || echo "stdout is NOT a tty"

Reproduce the cron environment rather than guessing at it:

# how the job actually runs: no terminal, minimal environment
setsid env -i HOME="$HOME" PATH=/usr/bin:/bin /path/to/script.sh < /dev/null > /tmp/out 2>&1
echo "exit=$?"; tail /tmp/out

If that fails where an interactive run succeeds, the terminal is the difference.

Find the failing ioctl directly:

strace -f -e trace=ioctl /path/to/command 2>&1 | grep ENOTTY
# ioctl(1, TCGETS, 0x7ffd…) = -1 ENOTTY (Inappropriate ioctl for device)
#        ^ fd 1 (stdout)  ^ terminal attributes -> no terminal
# ioctl(5, MTIOCTOP, …)    = -1 ENOTTY
#        ^                 ^ tape operation -> not a tape

The ioctl name in that output tells you which family you are in: TCGETS/TIOCGWINSZ is terminal, MTIOC* is tape.

Solutions / Resolution

1. Identify the family from the ioctl name — terminal or device. They have nothing in common beyond the errno.
2. Correct the tape parameter to name an actual tape device. Verify with mt status before re-running a backup.
3. For backup to disk, configure it properly rather than pointing a tape parameter at a file. Check what your version expects for a disk target — the parameters and their semantics differ between releases and between ontape and onbar.
4. For the terminal case, stop requiring a terminal. Where the code is yours, guard the call:

   if [ -t 1 ]; then
       cols=$(tput cols)
   else
       cols=80
   fi
   

   Where it is not, give the program a terminal or redirect cleanly:

   # explicit redirection so nothing inherits a half-open terminal
   /path/to/utility < /dev/null > /var/log/utility.log 2>&1
   

5. Do not allocate a pseudo-terminal to work around it unless the program genuinely needs one. script or unbuffer will make the error disappear and leave a job that depends on a terminal to run correctly, which is a worse position than the one you started in.
6. Re-test in the failing context, not interactively. An interactive test cannot reproduce this.

Examples

LTAPEDEV pointing at a file

$ grep -E '^(TAPEDEV|LTAPEDEV)' "$INFORMIXDIR/etc/$ONCONFIG"
TAPEDEV   /dev/st0
LTAPEDEV  /informix/backups/logical.log

$ stat -c '%F' /dev/st0 /informix/backups/logical.log
character special file
regular file

$ mt -f /informix/backups/logical.log status
/informix/backups/logical.log: Inappropriate ioctl for device

The archive device is a real tape; the logical-log device is a file. Writes to it would work, so the configuration looks functional until a control operation is attempted. mt reproduces the failure in one command and confirms the diagnosis without involving the engine.

Works by hand, fails from cron

$ /informix/scripts/nightly_report.sh
(succeeds)

$ setsid env -i HOME="$HOME" PATH=/usr/bin:/bin \
>   /informix/scripts/nightly_report.sh < /dev/null > /tmp/out 2>&1
$ grep -i ioctl /tmp/out
ioctl error: Inappropriate ioctl for device

$ strace -f -e trace=ioctl setsid /informix/scripts/nightly_report.sh < /dev/null 2>&1 \
>   | grep ENOTTY | head -2
ioctl(1, TIOCGWINSZ, 0x7ffc4a1c) = -1 ENOTTY (Inappropriate ioctl for device)

The script asks for the terminal width to format its output. Under cron there is no terminal. Defaulting the width when stdout is not a TTY is the fix; giving the job a pseudo-terminal is not.

Not a terminal problem at all, despite the wording

$ strace -f -e trace=ioctl ontape -a 2>&1 | grep ENOTTY
ioctl(6, MTIOCGET, 0x7ffd881c) = -1 ENOTTY (Inappropriate ioctl for device)

MTIOCGET is a magnetic-tape status request. The historic "Not a typewriter" wording sends people looking at terminals and stty; the ioctl name says plainly that this is the tape path.

Platform Note

errno 25 is ENOTTY on Linux, AIX, Solaris, HP-UX and the BSD-derived systems — stable, so the number is reliable. The wording is where platforms differ, and this catalogue carries the oldest form of it:

Source	Rendering
This catalogue	"Not a typewriter"
Linux, current	"Inappropriate ioctl for device"
Solaris, AIX	"Inappropriate ioctl for device"

Tape control interfaces are not portable. MTIOC* operations are the Linux and BSD family; AIX uses its own tape interface and tctl in place of mt; Solaris uses mt with different device paths. A backup integration written against one platform's tape ioctls will not simply work on another, which is a migration consideration rather than a runtime fault:

Task	Linux	Solaris	AIX
Tape status	mt -f /dev/st0 status	mt -f /dev/rmt/0 status	tctl -f /dev/rmt0 status
Terminal test	test -t 1, tty	same	same
Trace ioctls	strace -e trace=ioctl	truss -t ioctl	truss -t ioctl

Related Errors / Related Topics

• -19 — No such device. The device cannot do this at all, typically because no driver claims it; -25 is a device that works but does not support this particular operation.
• -15 — Block device required, the same class of mismatch caught at a different point.
• -6 — No such device or address, where nothing answers on the node.
• -24 — Too many open files, which also commonly appears in jobs run under cron with an environment that differs from interactive use.

Where -25 involves tape parameters, check TAPEDEV and LTAPEDEV together — they are set from the same configuration and are usually wrong together. Where it involves a terminal, the finding is that the job depends on interactive context, and there are generally others in the same estate that will surface the next time they are scheduled rather than run by hand.