<div><div dir="auto">Hi Eric</div></div><div dir="auto"><br></div><div dir="auto">The main problems of invoking nfd binary directly are:</div><div dir="auto">* NFD will fail to start if there’s no key in the keychain.</div><div dir="auto">* NFD could make certain files in the keychain to become owned by root, and subsequently cause applications under the non-root user account to experience file access errors.</div><div dir="auto">* Accessing the same keychain from multiple processes could easily trigger underlined behavior. In fact, if NFD binary and ndn-cxx were built with asserts enabled, you run NFD on user keychain and then run ndncert or ndnsec to add a new key, NFD would crash after a few seconds.</div><div dir="auto"><br></div><div dir="auto">Therefore, you should only start NFD with the method specify in packaging: systemd. This ensures NFD is started in the correct uid and a separate keychain.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 16, 2020 at 14:31 Eric Newberry <<a href="mailto:enewberry@cs.ucla.edu">enewberry@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div><p style="text-align:center"><font color="red"><strong>External Email</strong><br></font></p>
    <p>Hi Ishita,</p>
    <p>In commands 1 and 2 below, I notice that you're specifying "start
      nfd". If you're trying to run NFD directly, you should rewrite
      this part of these commands as just "nfd". (To clarify, there is
      nothing wrong with running NFD directly.)</p>
    <p>Hope this helps!</p></div><div><p><br>
    </p>
    <p>Eric<br>
    </p>
    </div></blockquote></div></div>