[Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket

[piaojun]

Hi Masayoshi,

On 2019/8/6 10:08, Masayoshi Mizuma wrote:
> Hi Jun,
> 
> On 8/3/19 10:48 PM, piaojun wrote:
>> Hi,
>>
>> On 2019/8/3 0:22, Masayoshi Mizuma wrote:
>>> Hi Stefan,
>>>
>>> On Fri, Aug 02, 2019 at 04:39:30PM +0100, Stefan Hajnoczi wrote:
>>>> On Thu, Aug 01, 2019 at 11:13:48AM -0400, Masayoshi Mizuma wrote:
>>>>> From: Masayoshi Mizuma <m.mizuma at jp.fujitsu.com>
>>>>>
>>>>> virtiofsd can run multiply even if the vhost_user_socket is
>>>>> same path.
>>>>>
>>>>>   ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share &
>>>>>   [1] 244965
>>>>>   virtio_session_mount: Waiting for vhost-user socket connection...
>>>>>   ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share &
>>>>>   [2] 244966
>>>>>   virtio_session_mount: Waiting for vhost-user socket connection...
>>>>>   ]#
>>>>>
>>>>> The file access from the guest works because the second virtiofsd
>>>>> handles that, however, the user will get confused the situation
>>>>> and may be the cause of unexpected problem. So it's better to
>>>>> prevent the multiple running.
>>>>>
>>>>> Change unlink() of the socket to the exit of virtiofsd so that the
>>>>> latter virtiofsd can fail on bind() as EADDRINUSE.
>>>>>
>>>>> Signed-off-by: Masayoshi Mizuma <m.mizuma at jp.fujitsu.com>
>>>>> ---
>>>>>  contrib/virtiofsd/fuse_lowlevel.c | 1 +
>>>>>  contrib/virtiofsd/fuse_virtio.c   | 1 -
>>>>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> This patch makes the UNIX domain socket act similar to a pidfile or
>>>> lockfile.  Does the user need to clean up the UNIX domain socket
>>>> manually before virtiofsd can restart again after a crash?
>>>>
>>>> This can be a robustness/reliability problem because we must assume that
>>>> crashes happen and recovery should not require human intervention.
>>>>
>>>> On the other hand, there are plenty of daemons that have long-lived UNIX
>>>> domain socket paths.  How do they handle crash recovery?
>>>
>>> It's good point, thanks.
>>> I think if the socket ramains due to the former crash, then the socket
>>> should be unlinked by virtiofsd, not manualy.
>>>
>>> virtiofsd should detect whether the socket is in use by the other
>>> virtiofsd or just remains by crash.
>>> I'll try to implement that...
>>
>> Do you mean that we need handle these two situations?
>> 1. The socket in use now;
>> 2. The socket remains by the former crashed virtiofsd.
>>
>> I guess it's a little hard to distinguish one from the other, as user
>> can start up virtiofsd simultaneously. If our goal is preventing
>> multiple instances, why not using file lock to guarantee single-instance?
>>
> 
> Thank you for your comments.
> Yes, I'm trying to implement that by using file lock.
> The unix domain socket cannot be locked because the open() fails as ENXIO,
> so I'm thinking that creates a regular file corresponding the socket name,
> and locks the file when virtiofsd boots. If the lock fails, then the socket
> is in use. If the lock successes, then the socket is available.
> I'll post the v2 patch...

That sounds reasonable.

Thanks,
Jun

> 
> Thanks!
> Masa
> .
>