Hi there,

Thanks for reaching out.

1. The online doc has been fixed and now specifies a different URL for CentOS7 and 8.
2. /var/run/daos_agent should be automatically created after enabling/starting the daos_agent systemd service (i.e. “systemctl enable/start daos_agent”).
   We have some instructions in the documentation on how to start the agent manually (w/o systemd), see https://docs.daos.io/v2.0/admin/predeployment_check/#runtime-directory-setup

That being said, this should not be required if you use RPMs/systemd.

3. Could you please advise what option(s) you pass to the dfuse command line? Can you set “export D_LOG_MASK=debug” and then run dfuse with the -f option and see what it logs?

Cheers,

Johann

Some post DAOS 2.0 installation and comments and questions:

1. We use a mix of CentOS 7 and 8 in our setup. However, the DAOS online documentation at "https://docs.daos.io/v2.0/QSG/setup_centos/" states the following URLas the repository to use when installing DAOS:

"https://packages.daos.io/v2.0/CentOS7/packages/x86_64/daos_packages.repo".

Of course, this lead to some installation problems as the is a specific CentOS 7 URL. Fixing the repository URL solved this problem, but only after some confusion about what going on. This probably needs some documentation clarification.

2. The DAOS agent creates a socket in /var/run/daos_agent. This isn't a persistent directory and the service doesn't create it, and it needs to be created on every boot for the agent to work properly.
a. This isn't mentioned in the documentation.
b. A systemd unit addition like "ExecStartPre=mkdir -p /var/run/daos_agent" is probably a good idea

3. Not sure why, but mounting a POSIX container using dfuse doesn't return for me. The process doesn't return. During that time, the mount is working (or so it seems), as a `mount` command does list a dfuse mount in the relevant directory, but the dfuse command didn't return to the CLI prompt.

Omer,

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.

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.

Omer