<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    The first thing I did was add that option to the nfs mount in the
    autofs config. I thought it didn't work but back then   I didn't
    have as good of a handle on the problem as I do now.  I found bug
    reports related to the default timeout for aufs not working. The bug
    reports said the timeout worked if you set itimplicitly for each
    share in the autofs config files. But that turned out being another
    red-herring.<br>
    <br>
    I am pretty sure this is a systemd problem. I just did an experiment
    -- I killed off the processes left over after a user logged out on 3
    different workstations but I did not unmount their home directory.
    Each of the 3 had the same 4 processes running, systemd,(sd-pam),
    ibus-daemon, and ibus-dconf. All I did was kill off those 4
    processes and after the usual time, the automounter unmounted their
    home directory. So I am about as sure as I can be that this is not
    an automounter or nfs problem. It's systemd not killing off those
    processes when a user logs out.<br>
    <br>
    Three days -- so far so good.<br>
    <br>
    <div class="moz-cite-prefix">On 04/22/2016 11:27 AM, Scott Plante
      wrote:<br>
    </div>
    <blockquote
      cite="mid:1223114249.1948.1461342431963.JavaMail.root@insightsys.com"
      type="cite">
      <style type="text/css">p { margin: 0; }</style>
      <div style="font-family: arial,helvetica,sans-serif; font-size:
        12pt; color: #000000">This isn't a solution to the underlying
        problem, but you might want to consider the "soft" option for
        the NFS mount. By default, NFS is designed to act like a
        physical disk in the sense that once the user initiates a write,
        it will block at that spot until the write completes. This is
        great if you have a NAS unit in the next rack slot from your
        database server. However, if you don't need quite that level of
        write assurance, the "soft" option acts more like a typical
        remote network share. If a problem occurs, the writer will just
        get an I/O error and be forced to deal with it. You won't get
        the kind of system hanging you experience with hard mounts. If
        you're just saving documents and doing that kind of basic file
        I/O this is perfect. You're mounting home directories, so you're
        somewhere in between, but depending on what your users are
        actually doing, soft mounts may be for you. Again, this doesn't
        explain the whole re-mounting read-only behavior but it may
        still be helpful for you to look into.<br>
        <br>
        <div>Scott</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Ale mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ale@ale.org">Ale@ale.org</a>
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>