Fix for #151231 leaves tmpfile fd open in actual job
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cron (Ubuntu) |
Fix Released
|
Undecided
|
Christian Kastner |
Bug Description
Binary package hint: cron
Maverick with cron 3.0pl1-114ubuntu1
I just upgraded a lucid machine to maverick. Now my backup cronjob spits out lots of warnings like:
File descriptor 5 (/tmp/tmpflCpLg8 (deleted)) leaked on lvcreate invocation. Parent PID 7092: /bin/bash
File descriptor 5 (/tmp/tmpflCpLg8 (deleted)) leaked on lvcreate invocation. Parent PID 7092: /bin/bash
File descriptor 5 (/tmp/tmpflCpLg8 (deleted)) leaked on lvcreate invocation. Parent PID 7092: /bin/bash
[...]
File descriptor 5 (/tmp/tmpflCpLg8 (deleted)) leaked on lvremove invocation. Parent PID 7092: /bin/bash
File descriptor 5 (/tmp/tmpflCpLg8 (deleted)) leaked on lvremove invocation. Parent PID 7092: /bin/bash
File descriptor 5 (/tmp/tmpflCpLg8 (deleted)) leaked on lvremove invocation. Parent PID 7092: /bin/bash
Thees are harmless but get sent to stderr => I now get a mail with these warnings each time the job runs. (I can't redirect stderr to /dev/null because I don't want to miss real problems).
It turns out that this problem was introduced to cron with this patch: http://
The patch makes cron use a tmpfile to fix bug #151231 and http://
The problem is that the file descriptor for this tmpfile is left open in the child which runs the actual cron job. Test case:
$ crontab -l
# stdout to log, stderr to mail
*/1 * * * * /home/jk/test.sh > /tmp/stdout.log
$ cat /home/jk/test.sh
#!/bin/sh
echo normal
echo warning/error >&2
echo
ls -al /proc/$$/fd
echo
# close /tmp/... fd
exec 5>&-
ls -al /proc/$$/fd
echo normal
echo warning/error >&2
After the job has run:
---
$ cat /tmp/stdout.log
normal
total 0
dr-x------ 2 jk jk 0 2010-10-24 16:17 .
dr-xr-xr-x 7 jk jk 0 2010-10-24 16:17 ..
lr-x------ 1 jk jk 64 2010-10-24 16:17 0 -> pipe:[2722425]
l-wx------ 1 jk jk 64 2010-10-24 16:17 1 -> /tmp/stdout.log
lr-x------ 1 jk jk 64 2010-10-24 16:17 10 -> /home/jk/test.sh
lrwx------ 1 jk jk 64 2010-10-24 16:17 2 -> /tmp/tmpflc7JPf (deleted)
lrwx------ 1 jk jk 64 2010-10-24 16:17 5 -> /tmp/tmpflc7JPf (deleted)
total 0
dr-x------ 2 jk jk 0 2010-10-24 16:17 .
dr-xr-xr-x 7 jk jk 0 2010-10-24 16:17 ..
lr-x------ 1 jk jk 64 2010-10-24 16:17 0 -> pipe:[2722425]
l-wx------ 1 jk jk 64 2010-10-24 16:17 1 -> /tmp/stdout.log
lr-x------ 1 jk jk 64 2010-10-24 16:17 10 -> /home/jk/test.sh
lrwx------ 1 jk jk 64 2010-10-24 16:17 2 -> /tmp/tmpflc7JPf (deleted)
normal
---
As you can see, fd 5 points to the tmpfile. It shouldn't be there! (fd 2 is ok)
I'm currently using "exec 5>&-" as a work-around for my backup cronjob - but that's an ugly fix of course.
Related branches
summary: |
- Fix for #151231 leave fd open in actual job + Fix for #151231 leaves tmpfile fd open in actual job |
(I added that patch, which was provided by Justin Pryzby, to cron)
Strange. On my Debian Squeeze system with cron-115 (diff to -114 is only in packaging), I get the following results with the test case you provided:
$ cat /tmp/stdout.log
normal
total 0
dr-x------ 2 chris chris 0 Oct 24 23:43 .
dr-xr-xr-x 7 chris chris 0 Oct 24 23:43 ..
lr-x------ 1 chris chris 64 Oct 24 23:43 0 -> pipe:[43931]
l-wx------ 1 chris chris 64 Oct 24 23:43 1 -> /tmp/stdout
lr-x------ 1 chris chris 64 Oct 24 23:43 10 -> /tmp/test.sh
l-wx------ 1 chris chris 64 Oct 24 23:43 2 -> /tmp/stderr
lrwx------ 1 chris chris 64 Oct 24 23:43 5 -> /tmp/tmpfznXN8E (deleted)
total 0
dr-x------ 2 chris chris 0 Oct 24 23:43 .
dr-xr-xr-x 7 chris chris 0 Oct 24 23:43 ..
lr-x------ 1 chris chris 64 Oct 24 23:43 0 -> pipe:[43931]
l-wx------ 1 chris chris 64 Oct 24 23:43 1 -> /tmp/stdout
lr-x------ 1 chris chris 64 Oct 24 23:43 10 -> /tmp/test.sh
l-wx------ 1 chris chris 64 Oct 24 23:43 2 -> /tmp/stderr
normal
---