7338 2015-02-19 18:33:35 +0000 coreutils-native fails to complete in rm_work because of recursive directory structure 2015-11-16 09:04:22 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.5 x86 Multiple VERIFIED WONTFIX Medium normal 1.9 1 mbroadst mbroadst bogdanx.a.voiculescu daniel.alexandrux.istrate douglasr2011 meta.mr.watcher meta.watcher sgw bogdanx.a.voiculescu --- --- No (bug/feature does not impact docs) oldest_to_newest 48944 0 mbroadst 2015-02-19 18:33:35 +0000 coreutils-native's configure script contains a check for whether getcwd handles long file names properly, which creates something like 850 recursive folders with the name "condir3". This compiles, and works as expected, however on the rm_work step in bitbake we receive the following failure: NOTE: recipe coreutils-native-8.21-r0: task do_rm_work: Started ERROR: Function failed: do_rm_work (log file is located at /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/log.do_rm_work.14228) ERROR: Logfile of failure stored in: /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/log.do_rm_work.14228 Log data follows: | DEBUG: Executing shell function do_rm_work | rm: cannot remove 'coreutils-8.21/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3': File name too long | WARNING: /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/run.do_rm_work.14228:1 exit 1 from | rm -rf $dir | ERROR: Function failed: do_rm_work (log file is located at /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/log.do_rm_work.14228) NOTE: recipe coreutils-native-8.21-r0: task do_rm_work: Failed ERROR: Task 8813 (virtual:native:/mnt/bitbake/build/detos/sources/openembedded-core/meta/recipes-core/coreutils/coreutils_8.21.bb, do_rm_work) failed with exit code '1' A possible solution is to exclude coreutils-native from running rm_work, but that leaves cruft behind. 48945 1 mbroadst 2015-02-19 18:37:21 +0000 Other relevant information: * This is a build that is being run inside a ubuntu 14.04 docker container. The behavior does not affect a similar container running ubuntu 13.03 inside. * We are using dora 48969 2 sgw 2015-02-20 22:11:22 +0000 Just to confirm, you do not see this issue with Ubuntu 13.03 container? Have you tried a newer release (16.2 or 1.7.1) or the git master. 48995 3 mbroadst 2015-02-23 18:47:41 +0000 This is a bit of a tricky situation, it seems totally unrelated to the base distro at this point (Ubuntu 14.04 vs 13.03), but rather because the CI bot running the job was running bitbake inside a docker container running inside another docker container. I'm not sure how likely it is that you will run into this with most users (probably not likely at all), but it does seem that rm_work is doing a "rm -rf $dir" and $dir is expanding to the entire path of that tree when it should just do e.g. "rm -rf confdir3" with no subfolders. Having said that, we were able to overcome the issue by simply disabling the getcwd-path-max.m4 configure check in coreutils, for anyone else that happens to find themselves in this cave :) 49477 4 sjolley.yp.pm 2015-03-16 19:30:13 +0000 The information appears to have been supplied. If this still is a needinfo status, please restate the question. 49844 5 Qi.Chen 2015-03-27 07:44:01 +0000 I cannot reproduce this problem. Is there any way to reproduce it on a sanity tested host of Yocto? Change the status to NEEDINFO util further information is provided. Regards, Chen Qi 50432 6 mbroadst 2015-04-20 21:13:24 +0000 I don't have time to continue to dig into this, changing to OBSOLETE for now 51246 7 douglasr2011 2015-05-25 21:24:03 +0000 The problem is that inside a Docker container, it is possible to create deeply nested directory structures that can't easily be deleted. I have opened an issue on the Docker project (https://github.com/docker/docker/issues/13451) including a few proposed work-arounds. The coreutils configuration runs code from getcwd-path-max.m4 (from the gnulib project), which includes C code to probe the limits of PATH_MAX for getcwd(). It does this by generating a directory structure that runs out to PATH_MAX, and testing that getcwd() remains well-behaved. At the end, it politely attempts to remove this directory structure, but silently fails. This does not have any immediate impact on the configuration of coreutils, though a second attempt to ./configure does have a different result (as mkdir confdir3/ fails). It leaves the user unable to delete the coreutils directory after building, as observed by Matt. We could potentially add the following work-around into the coreutils recipe, but I don't know that it's worth it: do_configure_append() { # When running in a Docker container, getcwd-path-max.m4 leaves behind # a deeply-nested structure of confdir3/ directories that can't be deleted using rm -fr. # See https://github.com/docker/docker/issues/13451 mv confdir3/confdir3/ fred || true rm -fr fred/ confdir3/ } 56482 8 bogdanx.a.voiculescu 2015-11-16 09:04:22 +0000 This will be fixed on docker side.