<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    I'm at home this morning on an ubuntu 15.10 system with a local home
    directory and no autofs. Ps shows that all 4 of those processes are
    running for me -- systemd, (sd-pam), ibus-daemon, and ibus-dconf.
    BTW, I googled for sd-pam and it looks like that is a fork/rename of
    the systemd process intended to desstroy the session. ie., sd-pam
    means "session destroy pam".  Apparently, when you fork/rename a
    process, you can rename it whatever you like including putting
    parens around the name. But those parens don't mean anything.<br>
    <br>
    I suspect ubuntu starts a per-user systemd process.  The one thing
    that might be non-standard for my users is that the default window
    manager is gnome, not unity. I'll have to experiment with that.
    Another thing I'll have to try is to uninstall the screen reader.
    I've mentioned before that I am blind. You can press Alt+Super+s to
    start the screen reader at the lightdm login screen. I don't *think*
    that requires a special process to run unless you actually use the
    hotkey. Most of my end-users would not be firing up the screen
    reader so I doubt it has anything to do with that.<br>
    <br>
    But I'll have to do a straight up install of ubuntu and log in to
    unity as a local user and then log out. The log out part might be
    tricky. I might have to get sighted assistance to do that. Oh, as I
    write this, it occurs to me that there is probably a hotkey in unity
    to log out. So set up a plain vanilla system, log in, log out, and
    see if those processes hang around.<br>
    <br>
    <div class="moz-cite-prefix">On 04/23/2016 10:43 AM, Jim Kinney
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEo=5PxuG4Sz6gb0vzCLf+=Z09kR-PEmHYed5o5ts2KnSjaYNw@mail.gmail.com"
      type="cite">
      <p dir="ltr">That is odd. I have systemd machines with automount
        and I don't see an individual systemd process per user. On my
        centos7 workstations, I have only a single systemd process for
        the systemd itself plus others named like systemd-udevd, etc,
        and all are root owned.</p>
      <div class="gmail_quote">On Apr 23, 2016 11:36 AM, "Todor Fassl"
        &lt;<a moz-do-not-send="true" href="mailto:fassl.tod@gmail.com">fassl.tod@gmail.com</a>&gt;
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div 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>On 04/22/2016 11:27 AM, Scott Plante wrote:<br>
            </div>
            <blockquote type="cite">
              <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></fieldset>
              <br>
              <pre>_______________________________________________
Ale mailing list
<a moz-do-not-send="true" href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a>
<a moz-do-not-send="true" href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a moz-do-not-send="true" href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a>
</pre>
            </blockquote>
            <br>
          </div>
          <br>
          _______________________________________________<br>
          Ale mailing list<br>
          <a moz-do-not-send="true" href="mailto:Ale@ale.org">Ale@ale.org</a><br>
          <a moz-do-not-send="true"
            href="http://mail.ale.org/mailman/listinfo/ale"
            rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
          See JOBS, ANNOUNCE and SCHOOLS lists at<br>
          <a moz-do-not-send="true"
            href="http://mail.ale.org/mailman/listinfo" rel="noreferrer"
            target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
          <br>
        </blockquote>
      </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>