All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Hanna Reitz <hreitz@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH 1/3] qsd: Add pre-init argument parsing pass
Date: Mon, 24 Jan 2022 10:23:09 +0100	[thread overview]
Message-ID: <871r0xij2a.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <87ab613d-3113-a6e2-fd1e-ad2cb861f041@redhat.com> (Hanna Reitz's message of "Mon, 24 Jan 2022 09:20:50 +0100")

Hanna Reitz <hreitz@redhat.com> writes:

> On 21.01.22 15:26, Markus Armbruster wrote:
>> Hanna Reitz <hreitz@redhat.com> writes:
>>
>>> On 21.01.22 11:27, Markus Armbruster wrote:
>>>> Hanna Reitz <hreitz@redhat.com> writes:
>>>>> The problem I face is that currently there is no ergonomic way to wait
>>>>> until the QSD is up and running (besides looping until the PID file
>>>>> exists), and I don’t think a utility program that doesn’t know the QSD
>>>>> could provide this.  (For example, it looks like daemonize(1) will
>>>>> have the parent exit immediately, regardless of whether the child is
>>>>> set up or not.)
>>>>
>>>> Why do you need to wait for QSD to be ready?
>>>>
>>>> I'm asking because with common daemons, I don't wait, I just connect to
>>>> their socket and start talking.  They'll reply only when ready.
>>>>
>>> That only applies when you want to talk to a socket, which I often
>>> don’t do.  Most of the time I use the storage daemon, I pass all
>>> --blockdev and --export options through the command line and don’t
>>>   create any socket at all.  When I use the QSD just to export some
>>> block device, I generally don’t need QMP.
>>
>> If you export via NBD, why can't you just connect to NBD socket?
>
> I’m not sure what exactly you mean by this, because the socket doesn’t
> exist before the QSD is launched.  If I launch the QSD in the
> background and have it create an NBD server on a Unix socket, then
> this socket will not exist until the respective --nbd-server option is
> parsed.  Trying to connect to it immediately after the QSD has been
> launched may work (if the QSD was quicker to parse the option and
> create the server than me trying to connect) or may yield ECONNREFUSED
> or ENOENT, depending on whether the socket file existed before or not.

This is similar to "with common daemons, [...] I just connect to their
socket and start talking."

> Also, outside of the iotests, I personally generally usually use FUSE
> exports instead of NBD exports.

You could wait for the mount to appear with stat -f.



  reply	other threads:[~2022-01-24  9:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22 11:41 [PATCH 0/3] qsd: Add --daemonize; and add job quit tests Hanna Reitz
2021-12-22 11:41 ` [PATCH 1/3] qsd: Add pre-init argument parsing pass Hanna Reitz
2021-12-30 16:00   ` Vladimir Sementsov-Ogievskiy
2022-01-03 16:14     ` Hanna Reitz
2022-01-19 12:58   ` Markus Armbruster
2022-01-19 13:44     ` Hanna Reitz
2022-01-19 17:21       ` Kevin Wolf
2022-01-20 16:00         ` Markus Armbruster
2022-01-20 16:31           ` Hanna Reitz
2022-01-21  6:10             ` Markus Armbruster
2022-01-21  8:43               ` Hanna Reitz
2022-01-21 10:27                 ` Markus Armbruster
2022-01-21 11:16                   ` Hanna Reitz
2022-01-21 14:26                     ` Markus Armbruster
2022-01-24  8:20                       ` Hanna Reitz
2022-01-24  9:23                         ` Markus Armbruster [this message]
2022-01-24  9:34                           ` Hanna Reitz
2021-12-22 11:41 ` [PATCH 2/3] qsd: Add --daemonize Hanna Reitz
2021-12-30 16:12   ` Vladimir Sementsov-Ogievskiy
2022-01-03 17:15     ` Hanna Reitz
2021-12-22 11:41 ` [PATCH 3/3] iotests/185: Add post-READY quit tests Hanna Reitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871r0xij2a.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.