Description of problem: "busybox cp" does not return a correct exit code when "No space left on device" Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Version Number: 5.6 Release Number: GA Architecture: x86 Kernel Version: 2.6.18-238.el5 Related Package Version: busybox-1.2.0-7.el5 How reproducible: Always Steps to Reproduce: 1. Make sure there is 4GB free space or more # df -lh Filesystem Size Used Avail Use% Mounted on /dev/sda2 48G 19G 26G 43% / /dev/sda1 494M 27M 442M 6% /boot tmpfs 7.8G 0 7.8G 0% /dev/shm /dev/sda5 19G 13G 4.4G 75% /mnt 2. # /sbin/busybox cp /root/16GB-file /mnt/ cp: Write Error: No space left on device 3. # echo $? 0 Actual results: "busybox cp" returns 0 when the command fails. Expected results: "busybox cp" returns 1 when the command fails. "cp" command in coreutils returns 1 when it fails. e.g. # /bin/cp 16GB-file /mnt/ cp: writing `/mnt/16GB-file': No space left on device # echo $? 1 Additional info: This issue was found when kdump prints "Saving core complete" even cp failed due to "No space left on device". <snip> /dump: 16/3784704 files (6.3% non-contiguous), 4255785/7558574 blocks kjournald starting. Commit interval 5 seconds EXT3 FS on sda5, internal journal EXT3-fs: mounted filesystem with ordered data mode. Copied 464.48 MB / 15972.5 MBCopied 916.48 MB / 15972.5 MBCopied 1360.48 MB / 15972.5 MBCopied 1808.48 MB / 15972.5 MBCopied 2260.48 MB / 15972.5 MBCopied 2700.48 MB / 15972.5 MBCopied 3144.48 MB / 15972.5 MBCopied 3592.48 MB / 15972.5 MBCopied 4036.48 MB / 15972.5 MBCopied 4484.48 MB / 15972.5 MBCopied 4928.48 MB / 15972.5 MBCopied 5368.48 MB / 15972.5 MBCopied 5808.48 MB / 15972.5 MBCopied 6248.48 MB / 15972.5 MBCopied 6684.48 MB / 15972.5 MBCopied 7124.48 MB / 15972.5 MBCopied 7560.48 MB / 15972.5 MBCopied 7996.48 MB / 15972.5 MBCopied 8440.48 MB / 15972.5 MBCopied 8876.48 MB / 15972.5 MBCopied 9316.57 MB / 15972.5 MBCopied 9760.48 MB / 15972.5 MBCopied 10196.5 MB / 15972.5 MBCopied 10632.5 MB / 15972.5 MBCopied 11060.5 MB / 15972.5 MBCopied 11488.5 MB / 15972.5 MBCopied 11916.5 MB / 15972.5 MBCopied 12348.5 MB / 15972.5 MBCopied 12780.5 MB / 15972.5 MBcp: Write Error: No space left on device Saving core complete md: stopping all md devices. Restarting system. </snip> --mkdumprd-- 2285 if [ "$CORE_COLLECTOR" == "cp" ]; then 2286 emit " monitor_cp_progress \$VMCORE-incomplete &" 2287 fi 2288 emit " $CORE_COLLECTOR /proc/vmcore \$VMCORE-incomplete >/dev/null" 2289 emit " exitcode=\$?" 2290 emit " if [ \$exitcode == 0 ]" 2291 emit " then" 2292 emit " mv \$VMCORE-incomplete \$VMCORE" 2293 emit " echo -e \"\\\033[0JSaving core complete\"" 2294 emit " fi"
(In reply to comment #0) > Related Package Version: busybox-1.2.0-7.el5 > > Steps to Reproduce: > 1. Make sure there is 4GB free space or more > # df -lh > Filesystem Size Used Avail Use% Mounted on > /dev/sda2 48G 19G 26G 43% / > /dev/sda1 494M 27M 442M 6% /boot > tmpfs 7.8G 0 7.8G 0% /dev/shm > /dev/sda5 19G 13G 4.4G 75% /mnt > > 2. # /sbin/busybox cp /root/16GB-file /mnt/ > cp: Write Error: No space left on device > > 3. # echo $? > 0 > > Actual results: > "busybox cp" returns 0 when the command fails. > > Expected results: > "busybox cp" returns 1 when the command fails. > > "cp" command in coreutils returns 1 when it fails. > e.g. > # /bin/cp 16GB-file /mnt/ > cp: writing `/mnt/16GB-file': No space left on device > # echo $? > 1 Can't reproduce: # mkdir ddd # mount -t tmpfs none ddd -o size=100000 Trying upstream (current busybox git): # ./busybox cp busybox_unstripped ddd; echo $? cp: write error: No space left on device 1 # rm ddd/* Trying binary extracted from busybox-1.2.0-7.el5 rpm (the version which doesn't work for you): # ./busybox-1.2.0-7.el5 cp busybox_unstripped ddd; echo $? cp: Write Error: No space left on device 1 # rm ddd/* Trying binary extracted from latest RHEL5 build, busybox-1.2.0-10.el5: # ./busybox-1.2.0-10.el5 cp busybox_unstripped ddd; echo $? cp: Write Error: No space left on device 1 # rm ddd/* In all cases, exit code is 1, as it should be.
I was finally able to reproduce it. It seems to happen when last write was partial: write(4, "\0\0\0\0\0\0\0\0\0"..., 8192) = 4096 write(4, "\0\0\0\0\0\0\0\0\0"..., 4096) = -1 ENOSPC (No space left on device) and even then, not always. I will look more into it (need to build bbox from source to track it further).
I found the bug: bb_copy_..() routines in 1.2.x were using size_t for total size to copy, and after 4Gb they rolled over to 0, which made bb_copy_..() to return success.
Test build with the fix: https://brewweb.devel.redhat.com/taskinfo?taskID=3534963
Sure. https://brewweb.devel.redhat.com/taskinfo?taskID=3566281
New build (non-test one): https://brewweb.devel.redhat.com/taskinfo?taskID=3748759
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0308.html