I’d be interested in seeing the stdout/stderr and logging from dfuse where this is happening. As you say the -f option should make it run in the foreground so if you’re not passing this then it
should background itself so you can get back a prompt. Even when it does go into the background it’ll wait until the fuse mount is registered with the kernel before detaching the terminal so that it can report any error to the user so there is code in there
to delay and then exit after forking so there is potential for an issue there although I’ve not known one before and we do have tests which use both methods.
Ashley.
From: daos@daos.groups.io <daos@daos.groups.io> on behalf of Omer via groups.io <omer.caspi@...> Date: Monday, 17 January 2022 at 14:32 To: daos@daos.groups.io <daos@daos.groups.io> Subject: Re: [daos] Post DAOS 2.0 installation and comments and questions
Hi,
Thanks for your reply.
1. I saw :). Cool.
2. I used to build DAOS and install it, so I had a script that did that for me, but yes, with RPM based solution this shouldn't be a concern. I fixed my unit file to do what I suggested to overcome this.
3. I tried " dfuse --pool=pool0 --container=cont0 -m /mnt/dfuse" and after a while " dfuse -f --pool=pool0 --container=cont0 -m /mnt/dfuse". I'm guessing the 2nd version is expected to not return as the '-f' suggests, but I didn't get a command prompt back
either way.