I login to run level 3. Use cryptsetup luksOpen and then mount to access an encrypted filesystem. Then use startx to start KDE4. After leaving kde, I unmount the encrypted filesystem, then use cyrptsetup luksClose to close the encrypted filesystem. This works in Mageia 1. In Mageia 2, it fails after I unmount the filesytem. The luksClose fails with the device busy. If I run killall on cupsd and on colord, then I can close the luks volume. Note that lsof -n does not show any process holding the device. It was only by comparing what processes were running before I started kde (the luksClose works if I don't start kde), with what processes were running after leaving kde, that I was able to figure out which processes were keeping the device busy. While the two programs shouldn't be holding devices they don't use, I suspect that forcing them to start before prefdm will fix the problem, although I have not confirmed this.
Meant to say before prefdm or getty.
CC: (none) => mageiaBlocks: (none) => 2120
I don't think forcing them to start at a particular time is the right answer. Users may restart them at any point, so that would be a flimsy solution at best. I also don't think this is a systemd issue per-se (hence I'm removing the blocks), I think the apps in question are simply keeping something busy when they shouldn't - likely they each need to be debugged and fixed accordingly. Can I as what file system you mounted? Was it /home?
Blocks: 2120 => (none)
(In reply to comment #2) > I also don't think this is a systemd issue per-se (hence I'm removing the > blocks), I think the apps in question are simply keeping something busy when > they shouldn't - likely they each need to be debugged and fixed accordingly. Then I guess this report should be split. One for cupsd the other for colord. > Can I as what file system you mounted? Was it /home? No. It's mounted as /var/mnt/data by a script called from my ~/.profile file, which uses pinentry-qt or pinentry-curses to get the passphrase, runs the cryptsetup luksOpen, then the mount. By calling the mount script from .profile, it gets called by prefdm or bash init, prior to the start of kde/gnome regardless of run level. Many of the directories in my /home are then symlinked to direcotries inside of the encrypted filesystem.
Would it be possible to temporarily remove the symlinks in your /home but go through the same proceedure. This way we'd at least know if they were keeping the mount point busy indirectly via the symlinks or directly via the /var/mnt path. This might not be too practical but it would at least help. While two bug reports might be needed, it might also be due to a common library, so maybe worth keeping it here until we've found out a bit more.
(In reply to comment #4) > Would it be possible to temporarily remove the symlinks in your /home but go > through the same proceedure. This way we'd at least know if they were keeping > the mount point busy indirectly via the symlinks or directly via the /var/mnt > path. Keep in mind /var/mnt/data has been unmounted. It's the luksClose that's failing. Rather then removing the symlinks, I logged out, logged in as root, and unmounted /home. The cryptsetup luksClose luks91 still returns device busy. After I killall colord and cupsd, the luksClose works.
Tried another test. Logged in as a different user, and started kde so that cupsd and colord were started. I then logged out of that user, logged in as my regular user, mounted the encrypted volume, and then started kde. After leaving kde, the unmount and luksclose works. So colord and cupsd are doing something that locks the device, only if it exists when they are started. The device, /dev/mapper/luks91 is a symlink to /dev/dm-21. I've looked through lsof -n when the luksClose fails, and don't see anything open for luks91, dm-21, or any of the symlinks I've found that point to dm-21. Running colord under strace also doesn't show anything obvious about how the device is getting locked.
Ahh right it's unmounted... sorry I missed the details. OK, this looks like an interesting problem :D My initial guess is that it's somehow blocking it due to some kind of inotify watch or something of that ilk. Not directly keeping files opened but somehow still doing it indirectly. I don't know enough about the internals of that stuff to know if this is a real possibility tho'. I'll try and speak with Richard Hughes (colord) to see if he has any ideas.
Reported upstream to Richard: https://bugs.freedesktop.org/show_bug.cgi?id=48637 feel free to comment there if you have an fd.o account. Lets see if he offers any thoughts on the matter.
Seems to have been fixed by the latest update to util-linux.
Status: NEW => RESOLVEDResolution: (none) => FIXED