<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" <<a href="mailto:fassl.tod@gmail.com">fassl.tod@gmail.com</a>> 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 href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a>
<a 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 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 href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a 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 href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div>