Re: schroot umount target is busy

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 09.07.24 08:52, Hombourger, Cedric (DI CTO FDS CES LX) wrote:
> On Mon, 2024-07-08 at 17:13 +0200, Jan Kiszka wrote:
>> On 08.07.24 16:17, Gökhan Çetin wrote:
>>> Hi everyone,
>>>
>>> Similarly, we have been observing do_image tasks fail sporadically
>>> in
>>> CI/CD pipelines for a while.
>>> You can see a few examples below:
>>>
>>> INFO - | E: 10mount: umount:
>>> /run/schroot/mount/isar-builder-31888f6e-6228-4bc8-9570-
>>> dd4d69ad25ba-367048-331187ba-b359-48ad-91f4-2962f4bdf32b: target is
>>> busy.
>>> INFO - | E: 10mount: rmdir: failed to remove
>>> '/var/run/schroot/mount/isar-builder-31888f6e-6228-4bc8-9570-
>>> dd4d69ad25ba-367048-331187ba-b359-48ad-91f4-2962f4bdf32b': Device
>>> or resource busy
>>> INFO - | E:
>>> isar-builder-31888f6e-6228-4bc8-9570-dd4d69ad25ba-367048-331187ba-
>>> b359-48ad-91f4-2962f4bdf32b: Chroot setup failed: stage=setup-stop
>>> INFO - NOTE: recipe .......: task do_image_swu: Failed
>>> ERROR - ERROR: Task (/builds/.......bb:do_image_swu) failed with
>>> exit
>>> code '1'
>>>
>>> INFO - | E: 10mount: umount:
>>> /run/schroot/mount/isar-builder-5f43627d-fad6-488f-bade-
>>> 57d0635ee0c6-408837-d15a1d4b-8c19-4fc8-9b5e-d2ccb3d67d82: target is
>>> busy.
>>> INFO - | E: 10mount: rmdir: failed to remove
>>> '/var/run/schroot/mount/isar-builder-5f43627d-fad6-488f-bade-
>>> 57d0635ee0c6-408837-d15a1d4b-8c19-4fc8-9b5e-d2ccb3d67d82': Device
>>> or resource busy
>>> INFO - | E:
>>> isar-builder-5f43627d-fad6-488f-bade-57d0635ee0c6-408837-d15a1d4b-
>>> 8c19-4fc8-9b5e-d2ccb3d67d82: Chroot setup failed: stage=setup-stop
>>> INFO - NOTE: recipe ......: task do_image_ova: Failed
>>> ERROR - ERROR: Task (/builds/.....bb:do_image_ova) failed with exit
>>> code '1'
>>>
>>> Do you have any information regarding the root cause?
>>
>> Trying once more to pull Cedric in (I think I used the wrong address
>> last time): Weren't you trying to resolve that with a lazy umount? Or
>> was it for a different corner of isar?
> 
> Correct. On our side, this issue is seen sporadically on servers
> managed by our IT where they have some proprietary / black-box services
> scanning the file-system when new mounts are discovered...
> 
> Have not found an elegant way to fix or work-around this (and obviously
> no luck in getting IT to remove their software or configure it
> differently)

Hehe, this is the point where moving to a VM will both be more secure
and faster.

Seriously, all we could do for such a scenario is adding some finite
retry loop. Messy.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/4e811a3d-fbfb-4030-ad02-f1cc0fa66799%40siemens.com.