strace crontab -e bombs on 10.04LTS

[ski]

Binary package hint: strace

strace is doing something wrong and winds up modifying the behavior of a running program -- in short, running "crontab -e" works fine, but running "strace crontab -e" results in an error being thrown before the editor is even invoked.

'crontab -e' returns an exit value of 0
'strace crontab -e' returns an exit value of 1

This reproducible on a fresh, up to date 10.04 LTS 64-bit install and verified on a machine that was upgraded a few times.

I set EDITOR=cat below to remove most of the binary ncurses noise of my default editor (nano).

[ski (skibrianski)]

attached is the strace.out generated from the above script

[ski (skibrianski)]

Looks like the change was made between 2008 and 2010...

debian-4.0$ export EDITOR=cat ; crontab -e ; ret1=$? ; strace crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2
... [snip] ...
return: 0, straced return: 0

debian-5.0$ export EDITOR=cat ; crontab -e >/dev/null ; ret1=$? ; echo === ; strace crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2
... [snip] ...
return: 0, straced return: 0

debian-6.0$ export EDITOR=cat ; crontab -e >/dev/null ; ret1=$? ; echo === ; strace crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2
... [snip] ...
return: 0, straced return: 1

ubuntu-8.04$ export EDITOR=cat ; crontab -e >/dev/null ; ret1=$? ; echo === ; strace crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2
... [snip] ...
return: 0, straced return: 0

ubuntu-10.04.3$ export EDITOR=cat ; crontab -e >/dev/null ; ret1=$? ; echo === ; strace crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2
... [snip] ...
return: 0, straced return: 1

[ski (skibrianski)]

Interesting to note that strace is actually changing the output of crontab -e in debian 4.0 (perhaps by calling isatty somewhere?), just not the return value. So it could be that a bug with crontab -e returning the right value was fixed in the 2008-2010 timeframe instead of a bug being introduced then.

<email address hidden>$ export EDITOR=cat ; crontab -e >/dev/null ; ret1=$? ; echo === ; strace -o/dev/null crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2 ; cat /etc/issue
No modification made
===
crontabs/ski: Permission denied

return: 0, straced return: 0
Debian GNU/Linux 4.0 \n \l

<email address hidden>$ export EDITOR=cat ; crontab -e >/dev/null ; ret1=$? ; echo === ; strace -o/dev/null crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2 ; cat /etc/issue
No modification made
===
/var/spool/cron/crontabs/ski: Permission denied

return: 0, straced return: 0
Debian GNU/Linux 5.0 \n \l

<email address hidden>$ export EDITOR=cat ; crontab -e >/dev/null ; ret1=$? ; echo === ; strace -o/dev/null crontab -e ; ret2=$? ; echo ; echo return: $ret1, straced return: $ret2 ; cat /etc/issue
No modification made
===
crontabs/ski/: fdopen: Permission denied
return: 0, straced return: 1
Debian GNU/Linux 6.0 \n \l

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.