Re: [PATCH v3 4/4] iotests/108: skip if fuse is unsuable

[Eric Farman <farman@linux.ibm.com>]

On 9/24/26 9:00 AM, Kevin Wolf wrote:
> Am 13.08.2026 um 20:37 hat Eric Farman geschrieben:
>> It is possible that the ability to fusermount is restricted
>> to privileged users. Rather than waiting for this test to
>> perform a mount and subsequently fail, perform a dummy mount
>> early on and skip the tests if fuse is not usable.
>>
>> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> 
> There is a typo in the subject line (s/unsuable/unusable/).
> 
>>   tests/qemu-iotests/108 | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
>> index bf808b3512..8dc725cf66 100755
>> --- a/tests/qemu-iotests/108
>> +++ b/tests/qemu-iotests/108
>> @@ -73,6 +73,23 @@ else
>>           _notrun 'Passwordless sudo for losetup or FUSE support required, but' \
>>                   'neither is available'
>>       fi
>> +
>> +    # Test to see if fuse is usable or not (permissions, etc.)
>> +    export_mp="$TEST_DIR/fuse-export"
>> +    touch "$export_mp"
>> +
>> +    response=$($QSD \
>> +        --blockdev null-co,node-name=export-node \
>> +        --export fuse,id=fuse-export,node-name=export-node,mountpoint="$export_mp",allow-other=off \
>> +        --pidfile "$TEST_DIR/qsd.pid" 2>&1)
> 
> If FUSE is available, this hangs because QSD doesn't exit by itself, but
> waits for clients to connect.
> 
> --daemonize might give you the right semantics (print errors while
> setting up the export to stderr, exit after initialising everything)
> when combined with your code below to kill QSD.

Good point. I note that similar logic exists elsewhere in 108, with a 
loop to wait for the qsd.pid file to disappear from a daemonized QSD, 
which would probably be warranted.

> 
>> +    if [[ $response = *"Failed to mount FUSE session to export"* ]]; then
>> +        _notrun 'FUSE support is not usable (permission error?)'
>> +    fi
> 
> Should this part use _notrun_on_fuse_error()?

Ah, of course. Not sure why I neglected to use that here.

> 
> Kevin
>