opened
loveshack
username_0
I still have this sort of problem inconsistently on RHEL6 with the latest source.  At other times I can do this without the error.   I don't know how to debug it off-hand, and probably don't have time to delve into kernel tracing.

````
# /usr/local/singularity/bin/singularity -q create xy
Creating a sparse image with a maximum size of 1024MiB...
Formatting image (/sbin/mkfs.ext3)
ERROR: Could not clear loop device: Device or resource busy
ERROR: Failed to detach loop device: /dev/loop12
Done. Image can be found at: xy
````

losetup -a shows
````
/dev/loop0: [fd00]:662797 (/dev/loop0)
/dev/loop1: [fd00]:662798 (/dev/loop1)
/dev/loop2: [fd02]:85 (), offset 31
[...]
/dev/loop10: [fd02]:34 (), offset 31
/dev/loop11: [fd02]:35 (), offset 31
````
with only 0 and 1 appearing on the right-hand side, and the loopN only seem to be associated with kernel threads in /proc.  They just show up from ps like
````
root      2389  0.0  0.0      0     0 ?        S<   15:12   0:00 [loop11]
````
continuing problems with loop devices
issue
created
gmkurtzer
username_1
Rhel6 64bit? I will keep running create and see if I can replicate it. Is it always on create, or do any other singularity commands yield this error?
comment
created
gmkurtzer
username_1
I have not been able to replicate this on several OS versions including C5, C6, and C7. I've ran this loop over and over and still no problem:

`for i in `seq -w 0 250`; do if ! sudo singularity create test.$i; then echo FAIL; break; fi ; done`

I have not had any loop devices uncleared or become associated with kernel threads that won't let go of them. I will leave this issue open for a while just incase anybody else comes across similar behavior and can describe a reproducer.
comment
created
truatpasteurdotfr
username_2
do you have a docker service running? defaulting to loop mounted sparse file storage
what does losetup -a reports?
comment
created
loveshack
username_0
I think others did.
comment
created
loveshack
username_0
I thought I posted output before.  I can't repeat it just now.
comment
created
gmkurtzer
username_1
Well, it is unfortunate that loops are consumables on the physical host... Is it possible that the docker daemon exhausted them and was causing or contributing to this? I've tried again, I can't replicate. :(
comment
created
loveshack
username_0
I saw the problem after killing docker.  As far as I can tell it needs
debugging at the kernel level, which I don't have time to look into.
comment
created
gmkurtzer
username_1
I will document that and leave this issue open for now incase anybody else sees something similar or related.
comment
created
gmkurtzer
username_1
Closing issues as this appears to be resolved now. If not, let me know and I'll reopen.

Thanks!
comment
closed
gmkurtzer
username_1
issue